mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 02:43:43 +00:00
updating for Windows 10
This commit is contained in:
@ -436,8 +436,8 @@
|
||||
#### [Windows Firewall with Advanced Security Design Guide](windows-firewall-with-advanced-security-design-guide.md)
|
||||
##### [Understanding the Windows Firewall with Advanced Security Design Process](understanding-the-windows-firewall-with-advanced-security-design-process.md)
|
||||
##### [Identifying Your Windows Firewall with Advanced Security Deployment Goals](identifying-your-windows-firewall-with-advanced-security-deployment-goals.md)
|
||||
###### [Protect Computers from Unwanted Network Traffic](protect-computers-from-unwanted-network-traffic.md)
|
||||
###### [Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md)
|
||||
###### [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md)
|
||||
###### [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md)
|
||||
###### [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)
|
||||
###### [Restrict Access to Only Specified Users or Computers](restrict-access-to-only-specified-users-or-computers.md)
|
||||
##### [Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design](mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md)
|
||||
|
@ -2,57 +2,58 @@
|
||||
title: Basic Firewall Policy Design (Windows 10)
|
||||
description: Basic Firewall Policy Design
|
||||
ms.assetid: 6f7af99e-6850-4522-b7f5-db98e6941418
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Basic Firewall Policy Design
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
Many organizations have a network perimeter firewall that is designed to prevent the entry of malicious traffic in to the organization's network, but do not have a host-based firewall enabled on each computer in the organization.
|
||||
Many organizations have a network perimeter firewall that is designed to prevent the entry of malicious traffic in to the organization's network, but do not have a host-based firewall enabled on each device in the organization.
|
||||
|
||||
The Basic Firewall Policy Design helps you to protect the computers in your organization from unwanted network traffic that gets through the perimeter defenses, or that originates from inside your network. In this design, you deploy firewall rules to each computer in your organization to allow traffic that is required by the programs that are used. Traffic that does not match the rules is dropped.
|
||||
The Basic Firewall Policy Design helps you to protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses, or that originates from inside your network. In this design, you deploy firewall rules to each device in your organization to allow traffic that is required by the programs that are used. Traffic that does not match the rules is dropped.
|
||||
|
||||
Traffic can be blocked or permitted based on the characteristics of each network packet: its source or destination IP address, its source or destination port numbers, the program on the computer that receives the inbound packet, and so on. This design can also be deployed together with one or more of the other designs that add IPsec protection to the network traffic permitted.
|
||||
Traffic can be blocked or permitted based on the characteristics of each network packet: its source or destination IP address, its source or destination port numbers, the program on the device that receives the inbound packet, and so on. This design can also be deployed together with one or more of the other designs that add IPsec protection to the network traffic permitted.
|
||||
|
||||
Many network administrators do not want to tackle the difficult task of determining all the appropriate rules for every program that is used by the organization, and then maintaining that list over time. In fact, most programs do not require specific firewall rules. The default behavior of Windows and most contemporary applications makes this task easy:
|
||||
|
||||
- On client computers, the default firewall behavior already supports typical client programs. Programs designed for Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows Vista create any required rules for you as part of the installation process. You only have to create a rule if the client program must be able to receive unsolicited inbound network traffic from another computer.
|
||||
- On client devices, the default firewall behavior already supports typical client programs. Programs create any required rules for you as part of the installation process. You only have to create a rule if the client program must be able to receive unsolicited inbound network traffic from another device.
|
||||
|
||||
- When you install a server program that must accept unsolicited inbound network traffic, the installation program likely creates or enables the appropriate rules on the server for you.
|
||||
|
||||
For example, when you install a server role in Windows Server 2012, Windows Server 2008 R2 or Windows Server 2008, the appropriate firewall rules are created and enabled automatically.
|
||||
For example, when you install a server role, the appropriate firewall rules are created and enabled automatically.
|
||||
|
||||
- For other standard network behavior, the predefined rules that are built into Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows Vista can easily be configured in a GPO and deployed to the computers in your organization.
|
||||
- For other standard network behavior, the predefined rules that are built into Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows Vista can easily be configured in a GPO and deployed to the devices in your organization.
|
||||
|
||||
For example, by using the predefined groups for Core Networking and File and Printer Sharing you can easily configure GPOs with rules for those frequently used networking protocols.
|
||||
|
||||
With few exceptions, the firewall can be enabled on all configurations of Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows Vista. Therefore, we recommended that you enable the firewall on every computer in your organization. This includes servers in your perimeter network, on mobile and remote clients that connect to the network, and on all servers and clients in your internal network.
|
||||
With few exceptions, the firewall can be enabled on all configurations. Therefore, we recommended that you enable the firewall on every device in your organization. This includes servers in your perimeter network, on mobile and remote clients that connect to the network, and on all servers and clients in your internal network.
|
||||
|
||||
**Caution**
|
||||
**Stopping the service associated with Windows Firewall with Advanced Security is not supported by Microsoft**.
|
||||
>**Caution:** Stopping the service associated with Windows Firewall with Advanced Security is not supported by Microsoft.
|
||||
|
||||
By default, in new installations, Windows Firewall is turned on in Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows Vista.
|
||||
By default, in new installations, Windows Firewall is turned on in Windows Server 2012, Windows 8, and later.
|
||||
|
||||
If you turn off the Windows Firewall with Advanced Security service you lose other benefits provided by the service, such as the ability to use IPsec connection security rules, Windows Service Hardening, and network protection from forms of attacks that use network fingerprinting. For more information about Windows Service Hardening, see <http://go.microsoft.com/fwlink/?linkid=104976>.
|
||||
If you turn off the Windows Firewall with Advanced Security service you lose other benefits provided by the service, such as the ability to use IPsec connection security rules, Windows Service Hardening, and network protection from forms of attacks that use network fingerprinting.
|
||||
|
||||
Third-party firewall software that is compatible with Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows Vista can programmatically disable only the parts of Windows Firewall with Advanced Security that might need to be disabled for compatibility. This is the recommended approach for third-party firewalls to coexist with the Windows Firewall; third-party party firewalls that comply with this recommendation have the certified logo from Microsoft.
|
||||
|
||||
|
||||
Compatible third-party firewall software can programmatically disable only the parts of Windows Firewall with Advanced Security that might need to be disabled for compatibility. This is the recommended approach for third-party firewalls to coexist with the Windows Firewall; third-party party firewalls that comply with this recommendation have the certified logo from Microsoft.
|
||||
|
||||
An organization typically uses this design as a first step toward a more comprehensive Windows Firewall with Advanced Security design that adds server isolation and domain isolation.
|
||||
|
||||
After implementing this design, your administrative team will have centralized management of the firewall rules applied to all computers that are running Windows in your organization.
|
||||
After implementing this design, you will have centralized management of the firewall rules applied to all devices that are running Windows in your organization.
|
||||
|
||||
**Important**
|
||||
If you also intend to deploy the [Domain Isolation Policy Design](domain-isolation-policy-design.md), or the [Server Isolation Policy Design](server-isolation-policy-design.md), we recommend that you do the design work for all three designs together, and then deploy in layers that correspond with each design.
|
||||
>**Important:** If you also intend to deploy the [Domain Isolation Policy Design](domain-isolation-policy-design.md), or the [Server Isolation Policy Design](server-isolation-policy-design.md), we recommend that you do the design work for all three designs together, and then deploy in layers that correspond with each design.
|
||||
|
||||
|
||||
|
||||
The basic firewall design can be applied to computers that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the firewall settings and rules.
|
||||
The basic firewall design can be applied to devices that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the firewall settings and rules.
|
||||
|
||||
For more information about this design:
|
||||
|
||||
- This design coincides with the deployment goal to [Protect Computers from Unwanted Network Traffic](protect-computers-from-unwanted-network-traffic.md).
|
||||
- This design coincides with the deployment goal to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md).
|
||||
|
||||
- To learn more about this design, see [Firewall Policy Design Example](firewall-policy-design-example.md).
|
||||
|
||||
@ -60,15 +61,6 @@ For more information about this design:
|
||||
|
||||
- To help you make the decisions required in this design, see [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md).
|
||||
|
||||
- For a list of detailed tasks that you can use to deploy your basic firewall policy design, see "Checklist: Implementing a Basic Firewall Policy Design" in the [Windows Firewall with Advanced Security Deployment Guide](http://go.microsoft.com/fwlink/?linkid=98308) at http://go.microsoft.com/fwlink/?linkid=98308.
|
||||
- For a list of detailed tasks that you can use to deploy your basic firewall policy design, see [Checklist: Implementing a Basic Firewall Policy Design](checklist-implementing-a-basic-firewall-policy-design.md).
|
||||
|
||||
**Next: **[Domain Isolation Policy Design](domain-isolation-policy-design.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,55 +2,51 @@
|
||||
title: Certificate-based Isolation Policy Design Example (Windows 10)
|
||||
description: Certificate-based Isolation Policy Design Example
|
||||
ms.assetid: 509b513e-dd49-4234-99f9-636fd2f749e3
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Certificate-based Isolation Policy Design Example
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
This design example continues to use the fictitious company Woodgrove Bank, as described in the sections [Firewall Policy Design Example](firewall-policy-design-example.md), [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md), and [Server Isolation Policy Design Example](server-isolation-policy-design-example.md).
|
||||
|
||||
One of the servers that must be included in the domain isolation environment is a computer running UNIX that supplies other information to the WGBank dashboard program running on the client computers. This computer sends updated information to the WGBank front-end servers as it becomes available, so it is considered unsolicited inbound traffic to the computers that receive this information.
|
||||
One of the servers that must be included in the domain isolation environment is a device running UNIX that supplies other information to the WGBank dashboard program running on the client devices. This device sends updated information to the WGBank front-end servers as it becomes available, so it is considered unsolicited inbound traffic to the devices that receive this information.
|
||||
|
||||
## Design requirements
|
||||
|
||||
One possible solution to this is to include an authentication exemption rule in the GPO applied to the WGBank front-end servers. This rule would instruct the front-end servers to accept traffic from the non-Windows device even though it cannot authenticate.
|
||||
|
||||
One possible solution to this is to include an authentication exemption rule in the GPO applied to the WGBank front-end servers. This rule would instruct the front-end servers to accept traffic from the non-Windows computer even though it cannot authenticate.
|
||||
A more secure solution, and the one selected by Woodgrove Bank, is to include the non-Windows device in the domain isolation design. Because it cannot join an Active Directory domain, Woodgrove Bank chose to use certificate-based authentication. Certificates are cryptographically-protected documents, encrypted in such a way that their origin can be positively confirmed.
|
||||
|
||||
A more secure solution, and the one selected by Woodgrove Bank, is to include the non-Windows computer in the domain isolation design. Because it cannot join an Active Directory domain, Woodgrove Bank chose to use certificate-based authentication. Certificates are cryptographically-protected documents, encrypted in such a way that their origin can be positively confirmed.
|
||||
|
||||
In this case, Woodgrove Bank used Microsoft Certificate Services, included with Windows Server 2008, to create the appropriate certificate. They might also have acquired and installed a certificate from a third-party commercial certification authority. They then used Group Policy to deploy the certificate to the front-end servers. The GPOs applied to the front-end servers also include updated connection security rules that permit certificate-based authentication in addition to Kerberos V5 authentication. They then manually installed the certificate on the UNIX server.
|
||||
In this case, Woodgrove Bank used Active Directory Certificate Services to create the appropriate certificate. They might also have acquired and installed a certificate from a third-party commercial certification authority. They then used Group Policy to deploy the certificate to the front-end servers. The GPOs applied to the front-end servers also include updated connection security rules that permit certificate-based authentication in addition to Kerberos V5 authentication. They then manually installed the certificate on the UNIX server.
|
||||
|
||||
The UNIX server is configured with firewall and IPsec connection security rules using the tools that are provided by the operating system vendor. Those rules specify that authentication is performed by using the certificate.
|
||||
|
||||
The creation of the IPsec connection security rules for a non-Windows computer is beyond the scope of this document, but support for a certificate that can be used to authenticate such a non-Windows computer by using the standard IPsec protocols is the subject of this design.
|
||||
The creation of the IPsec connection security rules for a non-Windows device is beyond the scope of this document, but support for a certificate that can be used to authenticate such a non-Windows device by using the standard IPsec protocols is the subject of this design.
|
||||
|
||||
The non-Windows computer can be effectively made a member of the boundary zone or the encryption zone based on the IPsec rules applied to the computer. The only constraint is that the main mode and quick mode encryption algorithms supported by the UNIX computer must also be supported by the Windows-based computers with which it communicates.
|
||||
The non-Windows device can be effectively made a member of the boundary zone or the encryption zone based on the IPsec rules applied to the device. The only constraint is that the main mode and quick mode encryption algorithms supported by the UNIX device must also be supported by the Windows-based devices with which it communicates.
|
||||
|
||||
**Other traffic notes:**
|
||||
|
||||
- None of the capabilities of the other designs discussed in this guide are compromised by the use of certificate authentication by a non-Windows computer.
|
||||
- None of the capabilities of the other designs discussed in this guide are compromised by the use of certificate authentication by a non-Windows device.
|
||||
|
||||
## Design details
|
||||
|
||||
Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the devices in their organization.
|
||||
|
||||
Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the computers in their organization.
|
||||
The inclusion of one or more non-Windows devices to the network requires only a simple addition to the GPOs for devices that must communicate with the non-Windows device. The addition is allowing certificate-based authentication in addition to the Active Directory–supported Kerberos V5 authentication. This does not require including new rules, just adding certificate-based authentication as an option to the existing rules.
|
||||
|
||||
The inclusion of one or more non-Windows computers to the network requires only a simple addition to the GPOs for computers that must communicate with the non-Windows computer. The addition is allowing certificate-based authentication in addition to the Active Directory–supported Kerberos V5 authentication. This does not require including new rules, just adding certificate-based authentication as an option to the existing rules.
|
||||
When multiple authentication methods are available, two negotiating devices agree on the first one in their lists that match. Because the majority of the devices in Woodgrove Bank's network run Windows, Kerberos V5 is listed as the first authentication method in the rules. Certificate-based authentication is added as an alternate authentication type.
|
||||
|
||||
When multiple authentication methods are available, two negotiating computers agree on the first one in their lists that match. Because the majority of the computers in Woodgrove Bank's network run Windows, Kerberos V5 is listed as the first authentication method in the rules. Certificate-based authentication is added as an alternate authentication type.
|
||||
By using the Active Directory Users and Computers snap-in, Woodgrove Bank created a group named NAG\_COMPUTER\_WGBUNIX. They then added the device accounts to this group for Windows devices that need to communicate with the non-Windows devices. If all the devices in the isolated domain need to be able to access the non-Windows devices, then the **Domain Computers** group can be added to the group as a member.
|
||||
|
||||
By using the Active Directory Users and Computers snap-in, Woodgrove Bank created a group named NAG\_COMPUTER\_WGBUNIX. They then added the computer accounts to this group for Windows computers that need to communicate with the non-Windows computers. If all the computers in the isolated domain need to be able to access the non-Windows computers, then the **Domain Computers** group can be added to the group as a member.
|
||||
|
||||
Woodgrove Bank then created a GPO that contains the certificate, and then attached security group filters to the GPO that allow read and apply permissions to only members of the NAG\_COMPUTER\_WGBUNIX group. The GPO places the certificate in the **Local Computer / Personal / Certificates** certificate store. The certificate used must chain back to a certificate that is in the **Trusted Root Certification Authorities** store on the local computer.
|
||||
Woodgrove Bank then created a GPO that contains the certificate, and then attached security group filters to the GPO that allow read and apply permissions to only members of the NAG\_COMPUTER\_WGBUNIX group. The GPO places the certificate in the **Local Computer / Personal / Certificates** certificate store. The certificate used must chain back to a certificate that is in the **Trusted Root Certification Authorities** store on the local device.
|
||||
|
||||
**Next: **[Designing a Windows Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,25 +2,32 @@
|
||||
title: Certificate-based Isolation Policy Design (Windows 10)
|
||||
description: Certificate-based Isolation Policy Design
|
||||
ms.assetid: 63e01a60-9daa-4701-9472-096c85e0f862
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Certificate-based Isolation Policy Design
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
In the certificate-based isolation policy design, you provide the same types of protections to your network traffic as described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) and [Server Isolation Policy Design](server-isolation-policy-design.md) sections. The only difference is the method used to share identification credentials during the authentication of your network traffic.
|
||||
|
||||
Domain isolation and server isolation help provide security for the computers on the network that run Windows and that can be joined to an Active Directory domain. However, in most corporate environments there are typically some computers that must run another operating system, such as Linux or UNIX. These computers cannot join an Active Directory domain, without a third-party package being installed. Also, some computers that do run Windows cannot join a domain for a variety of reasons. To rely on Kerberos V5 as the authentication protocol, the computer needs to be joined to the Active Directory and (for non-windows computers) support Kerberos as an authentication protocol.
|
||||
Domain isolation and server isolation help provide security for the devices on the network that run Windows and that can be joined to an Active Directory domain. However, in most corporate environments there are typically some devices that must run another operating system. These devices cannot join an Active Directory domain, without a third-party package being installed. Also, some devices that do run Windows cannot join a domain for a variety of reasons. To rely on Kerberos V5 as the authentication protocol, the device needs to be joined to the Active Directory and (for non-Windows devices) support Kerberos as an authentication protocol.
|
||||
|
||||
To authenticate with non-domain member computers, IPsec supports using standards-based cryptographic certificates. Because this authentication method is also supported by many third-party operating systems, it can be used as a way to extend your isolated domain to computers that do not run the Windows operating system.
|
||||
To authenticate with non-domain member devices, IPsec supports using standards-based cryptographic certificates. Because this authentication method is also supported by many third-party operating systems, it can be used as a way to extend your isolated domain to devices that do not run Windows.
|
||||
|
||||
The same principles of the domain and server isolation designs apply to this design. Only computers that can authenticate (in this case, by providing a specified certificate) can communicate with the computers in your isolated domain.
|
||||
The same principles of the domain and server isolation designs apply to this design. Only devices that can authenticate (in this case, by providing a specified certificate) can communicate with the devices in your isolated domain.
|
||||
|
||||
For computers that run Windows and that are part of an Active Directory domain, you can use Group Policy to deploy the certificates required to communicate with the computers that are trusted but are not part of the Active Directory domain. For other computers, you will have to either manually configure them with the required certificates, or use a third-party program to distribute the certificates in a secure manner.
|
||||
For Windows devices that are part of an Active Directory domain, you can use Group Policy to deploy the certificates required to communicate with the devices that are trusted but are not part of the Active Directory domain. For other devices, you will have to either manually configure them with the required certificates, or use a third-party program to distribute the certificates in a secure manner.
|
||||
|
||||
For more information about this design:
|
||||
For more info about this design:
|
||||
|
||||
- This design coincides with the deployment goals to [Protect Computers from Unwanted Network Traffic](protect-computers-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md), and optionally [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
|
||||
- This design coincides with the deployment goals to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md), and optionally [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
|
||||
|
||||
- To learn more about this design, see [Certificate-based Isolation Policy Design Example](certificate-based-isolation-policy-design-example.md).
|
||||
|
||||
@ -28,15 +35,6 @@ For more information about this design:
|
||||
|
||||
- To help you make the decisions required in this design, see [Planning Certificate-based Authentication](planning-certificate-based-authentication.md).
|
||||
|
||||
- For a list of tasks that you can use to deploy your certificate-based policy design, see "Checklist: Implementing a Certificate-based Isolation Policy Design" in the [Windows Firewall with Advanced Security Deployment Guide](http://go.microsoft.com/fwlink/?linkid=98308) at http://go.microsoft.com/fwlink/?linkid=98308.
|
||||
- For a list of tasks that you can use to deploy your certificate-based policy design, see [Checklist: Implementing a Certificate-based Isolation Policy Design](checklist-implementing-a-certificate-based-isolation-policy-design.md).
|
||||
|
||||
**Next: **[Evaluating Windows Firewall with Advanced Security Design Examples](evaluating-windows-firewall-with-advanced-security-design-examples.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,17 +2,24 @@
|
||||
title: Designing a Windows Firewall with Advanced Security Strategy (Windows 10)
|
||||
description: Designing a Windows Firewall with Advanced Security Strategy
|
||||
ms.assetid: 6d98b184-33d6-43a5-9418-4f24905cfd71
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Designing a Windows Firewall with Advanced Security Strategy
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
To select the most effective design for helping to protect the network, you must spend time collecting key information about your current computer environment. You must have a good understanding of what tasks the computers on the network perform, and how they use the network to accomplish those tasks. You must understand the network traffic generated by the programs running on the computers.
|
||||
To select the most effective design for helping to protect the network, you must spend time collecting key information about your current computer environment. You must have a good understanding of what tasks the devices on the network perform, and how they use the network to accomplish those tasks. You must understand the network traffic generated by the programs running on the devices.
|
||||
|
||||
- [Gathering the Information You Need](gathering-the-information-you-need.md)
|
||||
|
||||
- [Determining the Trusted State of Your Computers](determining-the-trusted-state-of-your-computers.md)
|
||||
- [Determining the Trusted State of Your Devices](determining-the-trusted-state-of-your-devices.md)
|
||||
|
||||
The information that you gather will help you answer the following questions. The answers will help you understand your security requirements and select the design that best matches those requirements. The information will also help you when it comes time to deploy your design, by helping you to build a deployment strategy that is cost effective and resource efficient. It will help you project and justify the expected costs associated with implementing the design.
|
||||
|
||||
@ -20,41 +27,21 @@ The information that you gather will help you answer the following questions. Th
|
||||
|
||||
- What traffic must always be blocked? Does your organization have policies that prohibit the use of specific programs? If so, what are the characteristics of the network traffic generated and consumed by the prohibited programs?
|
||||
|
||||
- What traffic on the network cannot be protected by IPsec because the computers or devices sending or receiving the traffic do not support IPsec?
|
||||
- What traffic on the network cannot be protected by IPsec because the devices or devices sending or receiving the traffic do not support IPsec?
|
||||
|
||||
- For each type of network traffic, does the default configuration of the firewall (block all unsolicited inbound network traffic, allow all outbound traffic) allow or block the traffic as required?
|
||||
|
||||
- Do you have an Active Directory domain (or forest of trusted domains) to which all your computers are joined? If you do not, then you cannot use Group Policy for easy mass deployment of your firewall and connection security rules. You also cannot easily take advantage of Kerberos V5 authentication that all domain clients can use.
|
||||
- Do you have an Active Directory domain (or forest of trusted domains) to which all your devices are joined? If you do not, then you cannot use Group Policy for easy mass deployment of your firewall and connection security rules. You also cannot easily take advantage of Kerberos V5 authentication that all domain clients can use.
|
||||
|
||||
- Which computers must be able to accept unsolicited inbound connections from computers that are not part of the domain?
|
||||
- Which devices must be able to accept unsolicited inbound connections from devices that are not part of the domain?
|
||||
|
||||
- Which computers contain data that must be encrypted when exchanged with another computer?
|
||||
- Which devices contain data that must be encrypted when exchanged with another computer?
|
||||
|
||||
- Which computers contain sensitive data to which access must be restricted to specifically authorized users and computers?
|
||||
- Which devices contain sensitive data to which access must be restricted to specifically authorized users and devices?
|
||||
|
||||
- Does your organization have specific network troubleshooting devices or computers (such as protocol analyzers) that must be granted unlimited access to the computers on the network, essentially bypassing the firewall?
|
||||
|
||||
## If you already have firewall or IPsec rules deployed
|
||||
- Does your organization have specific network troubleshooting devices or devices (such as protocol analyzers) that must be granted unlimited access to the devices on the network, essentially bypassing the firewall?
|
||||
|
||||
|
||||
Windows Firewall with Advanced Security in Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2 has many new capabilities that are not available in earlier versions of Windows.
|
||||
|
||||
If you already have a domain and/or server isolation deployment in your organization then you can continue to use your existing GPOs and apply them to computers running Windows 8 and Windows Server 2012.
|
||||
|
||||
**Note**
|
||||
Computers running Windows XP and Windows Server 2003 will not be able to participate in this domain and/or server isolation deployment plan.
|
||||
|
||||
|
||||
|
||||
This guide describes how to plan your groups and GPOs for an environment with a mix of operating systems, starting with Windows Vista and Windows Server 2008. Windows XP and Windows Server 2003 are not discussed in this guide. Details can be found in the section [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) later in this guide.
|
||||
This guide describes how to plan your groups and GPOs for an environment with a mix of operating systems. Details can be found in the section [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) later in this guide.
|
||||
|
||||
**Next: **[Gathering the Information You Need](gathering-the-information-you-need.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,30 +2,36 @@
|
||||
title: Domain Isolation Policy Design Example (Windows 10)
|
||||
description: Domain Isolation Policy Design Example
|
||||
ms.assetid: 704dcf58-286f-41aa-80af-c81720aa7fc5
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Domain Isolation Policy Design Example
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
This design example continues to use the fictitious company Woodgrove Bank, and builds on the example described in the [Firewall Policy Design Example](firewall-policy-design-example.md) section. See that example for an explanation of the basic corporate network infrastructure at Woodgrove Bank with diagrams.
|
||||
|
||||
## Design Requirements
|
||||
|
||||
|
||||
In addition to the basic protection provided by the firewall rules in the previous design example, the administrators of the network want to implement domain isolation to provide another layer of security to their networked computers. They want to create firewall and connection security rules that use authentication to reduce the risk of communicating with untrusted and potentially hostile computers.
|
||||
In addition to the basic protection provided by the firewall rules in the previous design example, you might want to implement domain isolation to provide another layer of security to their networked devices. You can create firewall and connection security rules that use authentication to reduce the risk of communicating with untrusted and potentially hostile devices.
|
||||
|
||||
The following illustration shows the traffic protection needed for this design example.
|
||||
|
||||

|
||||
|
||||
1. All computers on the Woodgrove Bank corporate network that are Active Directory domain members must authenticate inbound network traffic as coming from another computer that is a member of the domain. Unless otherwise specified in this section, Woodgrove Bank's computers reject all unsolicited inbound network traffic that is not authenticated. If the basic firewall design is also implemented, even authenticated inbound network traffic is dropped unless it matches an inbound firewall rule.
|
||||
1. All devices on the Woodgrove Bank corporate network that are Active Directory domain members must authenticate inbound network traffic as coming from another computer that is a member of the domain. Unless otherwise specified in this section, Woodgrove Bank's devices reject all unsolicited inbound network traffic that is not authenticated. If the basic firewall design is also implemented, even authenticated inbound network traffic is dropped unless it matches an inbound firewall rule.
|
||||
|
||||
2. The servers hosting the WGPartner programs must be able to receive unsolicited inbound traffic from computers owned by its partners, which are not members of Woodgrove Bank's domain.
|
||||
2. The servers hosting the WGPartner programs must be able to receive unsolicited inbound traffic from devices owned by its partners, which are not members of Woodgrove Bank's domain.
|
||||
|
||||
3. Client computers can initiate non-authenticated outbound communications with computers that are not members of the domain, such as browsing external Web sites. Unsolicited inbound traffic from non-domain members is blocked.
|
||||
3. Client devices can initiate non-authenticated outbound communications with devices that are not members of the domain, such as browsing external Web sites. Unsolicited inbound traffic from non-domain members is blocked.
|
||||
|
||||
4. Computers in the encryption zone require that all network traffic inbound and outbound must be encrypted, in addition to the authentication already required by the isolated domain.
|
||||
4. Devices in the encryption zone require that all network traffic inbound and outbound must be encrypted, in addition to the authentication already required by the isolated domain.
|
||||
|
||||
**Other traffic notes:**
|
||||
|
||||
@ -33,33 +39,20 @@ The following illustration shows the traffic protection needed for this design e
|
||||
|
||||
## Design Details
|
||||
|
||||
|
||||
Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the computers on its network.
|
||||
Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the devices on its network.
|
||||
|
||||
Setting up groups as described here ensures that you do not have to know what operating system a computer is running before assigning it to a group. As in the firewall policy design, a combination of WMI filters and security group filters are used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. For some groups, you might have four or even five GPOs.
|
||||
|
||||
The following groups were created by using the Active Directory Users and Computers MMC snap-in, all computers that run Windows were added to the correct groups, and then the appropriate GPO are applied to the group. To include a computer in the isolated domain or any one of its subordinate zones, simply add the computer's account in the appropriate group.
|
||||
The following groups were created by using the Active Directory Users and Computers MMC snap-in, all devices that run Windows were added to the correct groups, and then the appropriate GPO are applied to the group. To include a device in the isolated domain or any one of its subordinate zones, simply add the device's account in the appropriate group.
|
||||
|
||||
- **CG\_DOMISO\_ISOLATEDDOMAIN**. The members of this group participate in the isolated domain. After an initial pilot period, followed by a slowly increasing group membership, the membership of this group was eventually replaced with the entry **Domain Computers** to ensure that all computers in the domain participate by default. The WMI filters ensure that the GPO does not apply to domain controllers. GPOs with connection security rules to enforce domain isolation behavior are linked to the domain container and applied to the computers in this group. Filters ensure that each computer receives the correct GPO for its operating system type. The rules in the domain isolation GPO require Kerberos v5 authentication for inbound network connections, and request (but not require) it for all outbound connections.
|
||||
- **CG\_DOMISO\_ISOLATEDDOMAIN**. The members of this group participate in the isolated domain. After an initial pilot period, followed by a slowly increasing group membership, the membership of this group was eventually replaced with the entry **Domain Computers** to ensure that all devices in the domain participate by default. The WMI filters ensure that the GPO does not apply to domain controllers. GPOs with connection security rules to enforce domain isolation behavior are linked to the domain container and applied to the devices in this group. Filters ensure that each computer receives the correct GPO for its operating system type. The rules in the domain isolation GPO require Kerberos v5 authentication for inbound network connections, and request (but not require) it for all outbound connections.
|
||||
|
||||
- **CG\_DOMISO\_NO\_IPSEC**. This group is denied read or apply permissions on any of the domain isolation GPOs. Any computer that cannot participate in domain isolation, such as a DHCP server running UNIX, is added to this group.
|
||||
|
||||
- **CG\_DOMISO\_BOUNDARY**. This group contains the computer accounts for all the computers that are part of the boundary group able to receive unsolicited inbound traffic from untrusted computers. Members of the group receive a GPO that configures connection security rules to request (but not require) both inbound and outbound authentication.
|
||||
- **CG\_DOMISO\_BOUNDARY**. This group contains the computer accounts for all the devices that are part of the boundary group able to receive unsolicited inbound traffic from untrusted devices. Members of the group receive a GPO that configures connection security rules to request (but not require) both inbound and outbound authentication.
|
||||
|
||||
- **CG\_DOMISO\_ENCRYPTION**. This group contains the computer accounts for all the computers that require all inbound and outbound traffic to be both authenticated and encrypted. Members of the group receive a GPO that configures connection security and firewall rules to require both authentication and encryption on all inbound and outbound traffic.
|
||||
- **CG\_DOMISO\_ENCRYPTION**. This group contains the computer accounts for all the devices that require all inbound and outbound traffic to be both authenticated and encrypted. Members of the group receive a GPO that configures connection security and firewall rules to require both authentication and encryption on all inbound and outbound traffic.
|
||||
|
||||
**Note**
|
||||
If you are designing GPOs for only Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2, you can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, computers that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any computers that are incorrectly assigned to more than one group.
|
||||
|
||||
|
||||
>**Note:** If you are designing GPOs for only Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2, you can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, devices that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any devices that are incorrectly assigned to more than one group.
|
||||
|
||||
**Next: **[Server Isolation Policy Design Example](server-isolation-policy-design-example.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,19 +2,26 @@
|
||||
title: Domain Isolation Policy Design (Windows 10)
|
||||
description: Domain Isolation Policy Design
|
||||
ms.assetid: 7475084e-f231-473a-9357-5e1d39861d66
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Domain Isolation Policy Design
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
In the domain isolation policy design, you configure the computers on your network to accept only connections coming from computers that are authenticated as members of the same isolated domain.
|
||||
In the domain isolation policy design, you configure the devices on your network to accept only connections coming from devices that are authenticated as members of the same isolated domain.
|
||||
|
||||
This design typically begins with a network configured as described in the [Basic Firewall Policy Design](basic-firewall-policy-design.md) section. For this design, you then add connection security and IPsec rules to configure computers in the isolated domain to accept only network traffic from other computers that can authenticate as a member of the isolated domain. After implementing the new rules, your computers reject unsolicited network traffic from computers that are not members of the isolated domain.
|
||||
This design typically begins with a network configured as described in the [Basic Firewall Policy Design](basic-firewall-policy-design.md) section. For this design, you then add connection security and IPsec rules to configure devices in the isolated domain to accept only network traffic from other devices that can authenticate as a member of the isolated domain. After implementing the new rules, your devices reject unsolicited network traffic from devices that are not members of the isolated domain.
|
||||
|
||||
The isolated domain might not be a single Active Directory domain. It can consist of all the domains in a forest, or domains in separate forests that have two-way trust relationships configured between them.
|
||||
|
||||
By using connection security rules based on IPsec, you provide a logical barrier between computers even if they are connected to the same physical network segment.
|
||||
By using connection security rules based on IPsec, you provide a logical barrier between devices even if they are connected to the same physical network segment.
|
||||
|
||||
The design is shown in the following illustration, with the arrows that show the permitted communication paths.
|
||||
|
||||
@ -22,48 +29,36 @@ The design is shown in the following illustration, with the arrows that show the
|
||||
|
||||
Characteristics of this design, as shown in the diagram, include the following:
|
||||
|
||||
- Isolated domain (area A) - Computers in the isolated domain receive unsolicited inbound traffic only from other members of the isolated domain or from computers referenced in authentication exemption rules. Computers in the isolated domain can send traffic to any computer. This includes unauthenticated traffic to computers that are not in the isolated domain. Computers that cannot join an Active Directory domain, but that can use certificates for authentication, can be part of the isolated domain. For more information, see the [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md).
|
||||
- Isolated domain (area A) - Devices in the isolated domain receive unsolicited inbound traffic only from other members of the isolated domain or from devices referenced in authentication exemption rules. Devices in the isolated domain can send traffic to any device. This includes unauthenticated traffic to devices that are not in the isolated domain. Devices that cannot join an Active Directory domain, but that can use certificates for authentication, can be part of the isolated domain. For more info, see the [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md).
|
||||
|
||||
- Boundary zone (area B) - Computers in the boundary zone are part of the isolated domain but are allowed to accept inbound connections from untrusted computers, such as clients on the Internet.
|
||||
- Boundary zone (area B) - Devices in the boundary zone are part of the isolated domain but are allowed to accept inbound connections from untrusted devices, such as clients on the Internet.
|
||||
|
||||
Computers in the boundary zone request but do not require authentication to communicate. When a member of the isolated domain communicates with a boundary zone member the traffic is authenticated. When a computer that is not part of the isolated domain communicates with a boundary zone member the traffic is not authenticated.
|
||||
Devices in the boundary zone request but do not require authentication to communicate. When a member of the isolated domain communicates with a boundary zone member the traffic is authenticated. When a device that is not part of the isolated domain communicates with a boundary zone member the traffic is not authenticated.
|
||||
|
||||
Because boundary zone computers are exposed to network traffic from untrusted and potentially hostile computers, they must be carefully managed and secured. Put only the computers that must be accessed by external computers in this zone. Use firewall rules to ensure that network traffic is accepted only for services that you want exposed to non-domain member computers.
|
||||
Because boundary zone devices are exposed to network traffic from untrusted and potentially hostile devices, they must be carefully managed and secured. Put only the devices that must be accessed by external devices in this zone. Use firewall rules to ensure that network traffic is accepted only for services that you want exposed to non-domain member devices.
|
||||
|
||||
- Trusted non-domain members (area C) - Computers on the network that are not domain members or that cannot use IPsec authentication are allowed to communicate by configuring authentication exemption rules. These rules enable computers in the isolated domain to accept inbound connections from these trusted non-domain member computers.
|
||||
- Trusted non-domain members (area C) - Devices on the network that are not domain members or that cannot use IPsec authentication are allowed to communicate by configuring authentication exemption rules. These rules enable devices in the isolated domain to accept inbound connections from these trusted non-domain member devices.
|
||||
|
||||
- Untrusted non-domain members (area D) - Computers that are not managed by your organization and have an unknown security configuration must have access only to those computers required for your organization to correctly conduct its business. Domain isolation exists to put a logical barrier between these untrusted computers and your organization's computers.
|
||||
- Untrusted non-domain members (area D) - Devices that are not managed by your organization and have an unknown security configuration must have access only to those devices required for your organization to correctly conduct its business. Domain isolation exists to put a logical barrier between these untrusted Devices and your organization's devices.
|
||||
|
||||
After implementing this design, your administrative team will have centralized management of the firewall and connection security rules applied to the computers that are running Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows Vista in your organization.
|
||||
After implementing this design, your administrative team will have centralized management of the firewall and connection security rules applied to the devices in your organization.
|
||||
|
||||
**Important**
|
||||
This design builds on the [Basic Firewall Policy Design](basic-firewall-policy-design.md), and in turn serves as the foundation for the [Server Isolation Policy Design](server-isolation-policy-design.md). If you plan to deploy all three, we recommend that you do the design work for all three together, and then deploy in the sequence presented.
|
||||
>**Important:** This design builds on the [Basic Firewall Policy Design](basic-firewall-policy-design.md), and in turn serves as the foundation for the [Server Isolation Policy Design](server-isolation-policy-design.md). If you plan to deploy all three, we recommend that you do the design work for all three together, and then deploy in the sequence presented.
|
||||
|
||||
|
||||
This design can be applied to Devices that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the connection security rules.
|
||||
|
||||
This design can be applied to computers that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the connection security rules.
|
||||
In order to expand the isolated domain to include Devices that cannot be part of an Active Directory domain, see the [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md).
|
||||
|
||||
In order to expand the isolated domain to include computers that cannot be part of an Active Directory domain, see the [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md).
|
||||
For more info about this design:
|
||||
|
||||
For more information about this design:
|
||||
|
||||
- This design coincides with the deployment goals to [Protect Computers from Unwanted Network Traffic](protect-computers-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md), and optionally [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
|
||||
- This design coincides with the deployment goals to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md), and optionally [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
|
||||
|
||||
- To learn more about this design, see the [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md).
|
||||
|
||||
- Before completing the design, gather the information described in [Designing a Windows Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
|
||||
- Before completing the design, gather the info described in [Designing a Windows Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
|
||||
|
||||
- To help you make the decisions required in this design, see [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) and [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md).
|
||||
|
||||
- For a list of tasks that you can use to deploy your domain isolation policy design, see "Checklist: Implementing a Domain Isolation Policy Design" in the [Windows Firewall with Advanced Security Deployment Guide](http://go.microsoft.com/fwlink/?linkid=xxxxx) at http://go.microsoft.com/fwlink/?linkid=xxxxx.
|
||||
- For a list of tasks that you can use to deploy your domain isolation policy design, see [Checklist: Implementing a Domain Isolation Policy Design](checklist-implementing-a-domain-isolation-policy-design.md).
|
||||
|
||||
**Next:** [Server Isolation Policy Design](server-isolation-policy-design.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,13 +2,20 @@
|
||||
title: Evaluating Windows Firewall with Advanced Security Design Examples (Windows 10)
|
||||
description: Evaluating Windows Firewall with Advanced Security Design Examples
|
||||
ms.assetid: a591389b-18fa-4a39-ba07-b6fb61961cbd
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Evaluating Windows Firewall with Advanced Security Design Examples
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
The following Windows Firewall with Advanced Security design examples illustrate how you can use Windows Firewall with Advanced Security to improve the security of the computers connected to the network. You can use these topics to evaluate how the firewall and connection security rules work across all Windows Firewall with Advanced Security designs and to determine which design or combination of designs best suits the goals of your organization.
|
||||
The following Windows Firewall with Advanced Security design examples illustrate how you can use Windows Firewall with Advanced Security to improve the security of the devices connected to the network. You can use these topics to evaluate how the firewall and connection security rules work across all Windows Firewall with Advanced Security designs and to determine which design or combination of designs best suits the goals of your organization.
|
||||
|
||||
- [Firewall Policy Design Example](firewall-policy-design-example.md)
|
||||
|
||||
@ -18,11 +25,3 @@ The following Windows Firewall with Advanced Security design examples illustrate
|
||||
|
||||
- [Certificate-based Isolation Policy Design Example](certificate-based-isolation-policy-design-example.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,23 +2,29 @@
|
||||
title: Firewall Policy Design Example (Windows 10)
|
||||
description: Firewall Policy Design Example
|
||||
ms.assetid: 0dc3bcfe-7a4d-4a15-93a9-64b13bd775a7
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Firewall Policy Design Example
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
In this example, the fictitious company Woodgrove Bank is a financial services institution.
|
||||
|
||||
Woodgrove Bank has an Active Directory domain that provides Group Policy-based management for all their Windows-based computers. The Active Directory domain controllers also host Domain Name System (DNS) for host name resolution. Separate computers host Windows Internet Name Service (WINS) for network basic input/output system (NetBIOS) name resolution. A set of computers that are running UNIX provide the Dynamic Host Configuration Protocol (DHCP) services for automatic IP addressing.
|
||||
Woodgrove Bank has an Active Directory domain that provides Group Policy-based management for all their Windows devices. The Active Directory domain controllers also host Domain Name System (DNS) for host name resolution. Separate devices host Windows Internet Name Service (WINS) for network basic input/output system (NetBIOS) name resolution. A set of devices that are running UNIX provide the Dynamic Host Configuration Protocol (DHCP) services for automatic IP addressing.
|
||||
|
||||
Woodgrove Bank is in the process of migrating their computers from Windows Vista and Windows Server 2008 to Windows 8 and Windows Server 2012. A significant number of the computers at Woodgrove Bank continue to run Windows Vista and Windows Server 2008. Interoperability between the previous and newer operating systems must be maintained. Wherever possible, security features applied to the newer operating systems must also be applied to the previous operating systems.
|
||||
Woodgrove Bank is in the process of migrating their devices from Windows Vista and Windows Server 2008 to Windows 10 and Windows Server 2016 Technical Preview. A significant number of the devices at Woodgrove Bank continue to run Windows Vista and Windows Server 2008. Interoperability between the previous and newer operating systems must be maintained. Wherever possible, security features applied to the newer operating systems must also be applied to the previous operating systems.
|
||||
|
||||
A key line-of-business program called WGBank consists of a client program running on most of the desktop computers in the organization. This program accesses several front-end server computers that run the server-side part of WGBank. These front-end servers only do the processing — they do not store the data. The data is stored in several back-end database computers that are running Microsoft SQL Server.
|
||||
A key line-of-business program called WGBank consists of a client program running on most of the desktop devices in the organization. This program accesses several front-end server devices that run the server-side part of WGBank. These front-end servers only do the processing — they do not store the data. The data is stored in several back-end database devices that are running Microsoft SQL Server.
|
||||
|
||||
## Design requirements
|
||||
|
||||
|
||||
The network administrators want to implement Windows Firewall with Advanced Security throughout their organization to provide an additional security layer to their overall security strategy. They want to create firewall rules that allow their business programs to operate, while blocking network traffic that is not wanted.
|
||||
|
||||
The following illustration shows the traffic protection needs for this design example.
|
||||
@ -27,38 +33,38 @@ The following illustration shows the traffic protection needs for this design ex
|
||||
|
||||
1. The network infrastructure servers that are running services, such as Active Directory, DNS, DHCP, or WINS, can receive unsolicited inbound requests from network clients. The network clients can receive the responses from the infrastructure servers.
|
||||
|
||||
2. The WGBank front-end servers can receive unsolicited inbound traffic from the client computers and the WGBank partner servers. The WGBank client computers and partner servers can receive the response.
|
||||
2. The WGBank front-end servers can receive unsolicited inbound traffic from the client devices and the WGBank partner servers. The WGBank client devices and partner servers can receive the response.
|
||||
|
||||
3. The WGBank front-end servers can send updated information to the client computers to support real-time display. The clients do not poll for this unsolicited traffic, but must be able to receive it.
|
||||
3. The WGBank front-end servers can send updated information to the client devices to support real-time display. The clients do not poll for this unsolicited traffic, but must be able to receive it.
|
||||
|
||||
4. The WGBank back-end servers can receive SQL query requests from the WGBank front-end servers. The WGBank front-end servers can receive the corresponding responses.
|
||||
|
||||
5. There is no direct communications between the client computers and the WGBank back-end computers.
|
||||
5. There is no direct communications between the client devices and the WGBank back-end devices.
|
||||
|
||||
6. There is no unsolicited traffic from the WGBank back-end computers to the WGBank front-end servers.
|
||||
6. There is no unsolicited traffic from the WGBank back-end devices to the WGBank front-end servers.
|
||||
|
||||
7. Company policy prohibits the use of peer-to-peer file transfer software. A recent review by the IT staff found that although the perimeter firewall does prevent most of the programs in this category from working, two programs are being used by staff members that do not require an outside server. Firewall rules must block the network traffic created by these programs.
|
||||
|
||||
8. The WGBank partner servers can receive inbound requests from partner computers through the Internet.
|
||||
8. The WGBank partner servers can receive inbound requests from partner devices through the Internet.
|
||||
|
||||
Other traffic notes:
|
||||
|
||||
- Computers are not to receive any unsolicited traffic from any computer other than specifically allowed above.
|
||||
- Devices are not to receive any unsolicited traffic from any computer other than specifically allowed above.
|
||||
|
||||
- Other outbound network traffic from the client computers not specifically identified in this example is permitted.
|
||||
- Other outbound network traffic from the client devices not specifically identified in this example is permitted.
|
||||
|
||||
## Design details
|
||||
|
||||
|
||||
Woodgrove Bank uses Active Directory groups and Group Policy Objects to deploy the firewall settings and rules to the computers on their network. They know that they must deploy policies to the following collections of computers:
|
||||
Woodgrove Bank uses Active Directory groups and Group Policy Objects to deploy the firewall settings and rules to the devices on their network. They know that they must deploy policies to the following collections of devices:
|
||||
|
||||
- Client computers that run Windows 8, Windows 7, or Windows Vista
|
||||
- Client devices that run Windows 10, Windows 8, or Windows 7
|
||||
|
||||
- WGBank front-end servers that run Windows Server 2012 or Windows Server 2008 R2 (there are none in place yet, but their solution must support adding them)
|
||||
- WGBank front-end servers that run Windows Server 2016 Technical Preview, Windows Server 2012 R2, Windows Server 2012 or Windows Server 2008 R2 (there are none in place yet, but their solution must support adding them)
|
||||
|
||||
- WGBank partner servers that run Windows Server 2008
|
||||
|
||||
- WGBank back-end SQL Server computers that run Windows Server 2008 (there are none in place yet, but their solution must support adding them)
|
||||
- WGBank back-end SQL Server devices that run Windows Server 2008 (there are none in place yet, but their solution must support adding them)
|
||||
|
||||
- Infrastructure servers that run Windows Server 2008
|
||||
|
||||
@ -66,43 +72,35 @@ Woodgrove Bank uses Active Directory groups and Group Policy Objects to deploy t
|
||||
|
||||
- DHCP servers that run the UNIX operating system
|
||||
|
||||
After evaluating these sets of computers, and comparing them to the Active Directory organizational unit (OU) structure, Woodgrove Bank network administrators determined that there was not a good one-to-one match between the OUs and the sets. Therefore the firewall GPOs will not be linked directly to OUs that hold the relevant computers. Instead, the GPOs are linked to the domain container in Active Directory, and then WMI and group filters are attached to the GPO to ensure that it is applied to the correct computers.
|
||||
After evaluating these sets of devices, and comparing them to the Active Directory organizational unit (OU) structure, Woodgrove Bank network administrators determined that there was not a good one-to-one match between the OUs and the sets. Therefore the firewall GPOs will not be linked directly to OUs that hold the relevant devices. Instead, the GPOs are linked to the domain container in Active Directory, and then WMI and group filters are attached to the GPO to ensure that it is applied to the correct devices.
|
||||
|
||||
Setting up groups as described here ensures that you do not have to know what operating system a computer is running before assigning it to a group. A combination of WMI filters and security group filters are used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. For some groups, you might have four or even five GPOs.
|
||||
|
||||
The following groups were created by using the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, and all computers that run Windows were added to the correct groups:
|
||||
The following groups were created by using the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, and all devices that run Windows were added to the correct groups:
|
||||
|
||||
- **CG\_FIREWALL\_ALLCOMPUTERS**. Add the predefined and system managed **Domain computers** group as a member of this group. All members of the FIREWALL\_ALLCOMPUTERS group receive an operating system-specific GPO with the common firewall rules applied to all computers.
|
||||
- **CG\_FIREWALL\_ALLCOMPUTERS**. Add the predefined and system managed **Domain computers** group as a member of this group. All members of the FIREWALL\_ALLCOMPUTERS group receive an operating system-specific GPO with the common firewall rules applied to all devices.
|
||||
|
||||
The two computer types (client and server) are distinguished by using a WMI filters to ensure that only the policy intended for computers that are running a client version of Windows can be applied to that computer. A similar WMI filter on the server GPO ensures that only computers that are running server versions of Windows can apply that GPO. Each of the GPOs also have security group filters to prevent members of the group FIREWALL\_NO\_DEFAULT from receiving either of these two GPOs.
|
||||
The two device types (client and server) are distinguished by using a WMI filters to ensure that only the policy intended for devices that are running a client version of Windows can be applied to that computer. A similar WMI filter on the server GPO ensures that only devices that are running server versions of Windows can apply that GPO. Each of the GPOs also have security group filters to prevent members of the group FIREWALL\_NO\_DEFAULT from receiving either of these two GPOs.
|
||||
|
||||
- Client computers receive a GPO that configures Windows Firewall with Advanced Security to enforce the default Windows Firewall behavior (allow outbound, block unsolicited inbound). The client default GPO also includes the built-in firewall rule groups Core Networking and File and Printer Sharing. The Core Networking group is enabled for all profiles, whereas the File and Printer Sharing group is enabled for only the Domain and Private profiles. The GPO also includes inbound firewall rules to allow the WGBank front-end server dashboard update traffic, and rules to prevent company-prohibited programs from sending or receiving network traffic, both inbound and outbound.
|
||||
- Client devices receive a GPO that configures Windows Firewall with Advanced Security to enforce the default Windows Firewall behavior (allow outbound, block unsolicited inbound). The client default GPO also includes the built-in firewall rule groups Core Networking and File and Printer Sharing. The Core Networking group is enabled for all profiles, whereas the File and Printer Sharing group is enabled for only the Domain and Private profiles. The GPO also includes inbound firewall rules to allow the WGBank front-end server dashboard update traffic, and rules to prevent company-prohibited programs from sending or receiving network traffic, both inbound and outbound.
|
||||
|
||||
- Server computers receive a GPO that includes similar firewall configuration to the client computer GPO. The primary difference is that the rules are enabled for all profiles (not just domain and private). Also, the rules for WGBank dashboard update are not included, because it is not needed on server computers.
|
||||
- Server devices receive a GPO that includes similar firewall configuration to the client computer GPO. The primary difference is that the rules are enabled for all profiles (not just domain and private). Also, the rules for WGBank dashboard update are not included, because it is not needed on server devices.
|
||||
|
||||
All rules are scoped to allow network traffic only from computers on Woodgrove Bank's corporate network.
|
||||
All rules are scoped to allow network traffic only from devices on Woodgrove Bank's corporate network.
|
||||
|
||||
- **CG\_FIREWALL\_NO\_DEFAULT**. Members of this group do not receive the default firewall GPO. Computers are added to this group if there is a business requirement for it to be exempted from the default firewall behavior. The use of a group to represent the exceptions instead of the group members directly makes it easier to support the dynamic nature of the client computer population. A new computer joined to the domain is automatically given the appropriate default firewall GPO, unless it is a member of this group.
|
||||
- **CG\_FIREWALL\_NO\_DEFAULT**. Members of this group do not receive the default firewall GPO. Devices are added to this group if there is a business requirement for it to be exempted from the default firewall behavior. The use of a group to represent the exceptions instead of the group members directly makes it easier to support the dynamic nature of the client computer population. A new computer joined to the domain is automatically given the appropriate default firewall GPO, unless it is a member of this group.
|
||||
|
||||
- **CG\_FIREWALL\_WGB\_FE**. This group contains the computer accounts for all the WGBank front-end server computers. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow unsolicited WGBank client traffic. Computers in this group also receive the default firewall GPO.
|
||||
- **CG\_FIREWALL\_WGB\_FE**. This group contains the computer accounts for all the WGBank front-end server devices. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow unsolicited WGBank client traffic. Devices in this group also receive the default firewall GPO.
|
||||
|
||||
- **CG\_FIREWALL\_WGB\_SQL**. This group contains the computer accounts for all the WGBank back-end computers that run SQL Server. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow the SQL Server program to receive unsolicited queries only from the WGBank front-end servers. Computers in this group also receive the default firewall GPO.
|
||||
- **CG\_FIREWALL\_WGB\_SQL**. This group contains the computer accounts for all the WGBank back-end devices that run SQL Server. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow the SQL Server program to receive unsolicited queries only from the WGBank front-end servers. Devices in this group also receive the default firewall GPO.
|
||||
|
||||
- **CG\_FIREWALL\_BOUNDARY\_WGBANKFE**. This group contains the computer accounts for the servers that host Web services that can be accessed from the Internet. Members of this group receive a GPO that adds an inbound firewall rule to allow inbound HTTP and HTTPS network traffic from any address, including the Internet. Computers in this group also receive the default firewall GPO.
|
||||
- **CG\_FIREWALL\_BOUNDARY\_WGBANKFE**. This group contains the computer accounts for the servers that host Web services that can be accessed from the Internet. Members of this group receive a GPO that adds an inbound firewall rule to allow inbound HTTP and HTTPS network traffic from any address, including the Internet. Devices in this group also receive the default firewall GPO.
|
||||
|
||||
- **CG\_FIREWALL\_WINS**. This group contains the computer accounts for all the WINS server computers. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with an inbound firewall rule to allow unsolicited inbound requests from WINS clients. Computers in this group also receive the default firewall GPO.
|
||||
- **CG\_FIREWALL\_WINS**. This group contains the computer accounts for all the WINS server devices. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with an inbound firewall rule to allow unsolicited inbound requests from WINS clients. Devices in this group also receive the default firewall GPO.
|
||||
|
||||
- **CG\_FIREWALL\_ADDC**. This group contains all the computer accounts for the Active Directory domain controller server computers. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow unsolicited Active Directory client and server-to-server traffic. Computers in this group also receive the default firewall GPO.
|
||||
- **CG\_FIREWALL\_ADDC**. This group contains all the computer accounts for the Active Directory domain controller server devices. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow unsolicited Active Directory client and server-to-server traffic. Devices in this group also receive the default firewall GPO.
|
||||
|
||||
In your own design, create a group for each computer role in your organization that requires different or additional firewall rules. For example, file servers and print servers require additional rules to allow the incoming network traffic for those functions. If a function is ordinarily performed on most computers on the network, you might consider adding computers performing those roles to the common default firewall GPO set, unless there is a security reason not to include it there.
|
||||
In your own design, create a group for each computer role in your organization that requires different or additional firewall rules. For example, file servers and print servers require additional rules to allow the incoming network traffic for those functions. If a function is ordinarily performed on most devices on the network, you might consider adding devices performing those roles to the common default firewall GPO set, unless there is a security reason not to include it there.
|
||||
|
||||
**Next: **[Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,33 +2,31 @@
|
||||
title: Gathering Information about Your Active Directory Deployment (Windows 10)
|
||||
description: Gathering Information about Your Active Directory Deployment
|
||||
ms.assetid: b591b85b-12ac-4329-a47e-bc1b03e66eb0
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Gathering Information about Your Active Directory Deployment
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
Active Directory is another important item about which you must gather information. You must understand the forest structure. This includes domain layout, organizational unit (OU) architecture, and site topology. This information makes it possible to know where computers are currently placed, their configuration, and the impact of changes to Active Directory that result from implementing Windows Firewall with Advanced Security. Review the following list for information needed:
|
||||
Active Directory is another important item about which you must gather information. You must understand the forest structure. This includes domain layout, organizational unit (OU) architecture, and site topology. This information makes it possible to know where devices are currently placed, their configuration, and the impact of changes to Active Directory that result from implementing Windows Firewall with Advanced Security. Review the following list for information needed:
|
||||
|
||||
- **Names and number of forests**. The forest (not the domain) is the security boundary in an Active Directory implementation. You must understand the current Active Directory architecture to determine the most effective strategy for deploying your firewall and connection security rules using Group Policy. It also enables you to understand which computers can be isolated and how best to accomplish the required degree of isolation.
|
||||
- **Names and number of 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 computers are domain members.
|
||||
- **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 computers in different Active Directory domains.
|
||||
- **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 usually aligned with the network topology. Understanding how sites are defined in Active Directory will help provide insight into replication and other details. Site architecture can provide a better understanding of the current Active Directory deployment.
|
||||
|
||||
- **OU structure**. OUs are logical constructs and can therefore be molded to fit many different requirements and goals. The OU structure is an ideal place to examine how Group Policy is currently used and how the OUs are laid out. You do not have to redesign an already implemented OU structure in order to effectively deploy firewall and connection security policy, but an understanding of the structure helps you know what WMI or group filtering is required to apply each GPO to the correct computers.
|
||||
|
||||
- **Existing IPsec policy**. Because this project culminates in the implementation of IPsec policy, you must understand how the network currently uses IPsec (if at all). Windows Firewall with Advanced Security connection security rules for Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2 are not compatible with earlier versions of Windows. If you already have IPsec policies deployed to computers running Windows XP and Windows Server 2003 in your organization, you must ensure that the new IPsec policies you deploy enable computers using either the old or new IPsec policies to communicate with each other.
|
||||
|
||||
**Next: **[Gathering Information about Your Computers](gathering-information-about-your-computers.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- **OU structure**. OUs are logical constructs and can therefore be molded to fit many different requirements and goals. The OU structure is an ideal place to examine how Group Policy is currently used and how the OUs are laid out. You do not have to redesign an already implemented OU structure in order to effectively deploy firewall and connection security policy, but an understanding of the structure helps you know what WMI or group filtering is required to apply each GPO to the correct 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 Firewall with Advanced Security connection security rules for versions of Windows prior to Windows Vista and Windows Server 2008 are not 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)
|
||||
|
@ -1,58 +0,0 @@
|
||||
---
|
||||
title: Gathering Information about Your Computers (Windows 10)
|
||||
description: Gathering Information about Your Computers
|
||||
ms.assetid: 7f7cd3b9-de8e-4fbf-89c6-3d1a47bc2beb
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Gathering Information about Your Computers
|
||||
|
||||
|
||||
One of the most valuable benefits of conducting an asset discovery project is the large amount of data that is obtained about the client and server computers on the network. When you start designing and planning your isolation zones, you must make decisions that require accurate information about the state of all hosts to ensure that they can use IPsec as planned.
|
||||
|
||||
Capture the following information from each computer:
|
||||
|
||||
- **Computer name**. This name is the computer's NetBIOS or DNS name that identifies the computer on the network. Because a computer can have more than one media access control (MAC) or IP address, the computer's name is one of the criteria that can be used to determine uniqueness on the network. Because computer names can be duplicated under some circumstances, the uniqueness should not be considered absolute.
|
||||
|
||||
- **IP address for each network adapter**. The IP address is the address that is used with the subnet mask to identify a host on the network. An IP address is not an effective way to identify an asset because it is often subject to change.
|
||||
|
||||
- **Operating system, service pack, and hotfix versions**. The operating system version is a key factor in determining the ability of a host to communicate by using IPsec. It is also important to track the current state of service packs and updates that might be installed, because these are often used to determine that minimum security standards have been met.
|
||||
|
||||
- **Domain membership**. This information is used to determine whether a computer can obtain IPsec policy from Active Directory or whether it must use a local IPsec policy.
|
||||
|
||||
- **Physical location**. This information is just the location of the device in your organization. It can be used to determine whether a device can participate in a specific isolation group based on its location or the location of the devices that it communicates with regularly.
|
||||
|
||||
- **Hardware type or role**. Some tools that perform host discovery can provide this information by querying the hardware information and running applications to determine its type, such as server, workstation, or portable computer. You can use this information to determine the appropriate IPsec policy to assign, whether a specific computer can participate in isolation, and in which isolation group to include the computer.
|
||||
|
||||
After collecting all this information and consolidating it into a database, perform regular discovery efforts periodically to keep the information current. You need the most complete and up-to-date picture of the managed hosts on their networks to create a design that matches your organization's requirements.
|
||||
|
||||
You can use various methods to gather data from the hosts on the network. These methods range from high-end, fully automated systems to completely manual data collection. Generally, the use of automated methods to gather data is preferred over manual methods for reasons of speed and accuracy.
|
||||
|
||||
## Automated Discovery
|
||||
|
||||
|
||||
Using an automated auditing network management system such as Microsoft System Center Configuration Manager (formerly known as Systems Management Server) provides valuable information about the current state of the IT infrastructure.
|
||||
|
||||
For more information about how System Center Configuration Manager 2007 can help perform automated information gathering, see <http://go.microsoft.com/fwlink/?linkid=110412>.
|
||||
|
||||
## Manual Discovery
|
||||
|
||||
|
||||
The biggest difference between manual discovery methods and automated methods is time.
|
||||
|
||||
You can use the Windows Script Host (WSH), VBScript, and Windows Management Instrumentation (WMI) to create a script file that can collect the system configuration information. VBScript and WMI are built-in to Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2. Starting with Windows Server 2008, Windows PowerShell is included with the operating system. For more information, see “Scripting with Windows PowerShell” (<http://go.microsoft.com/fwlink/?linkid=110413>).
|
||||
|
||||
Whether you use an automatic, manual, or hybrid option to gather the information, one of the biggest issues that can cause problems to the design is capturing the changes between the original inventory scan and the point at which the implementation is ready to start. After the first scan has been completed, make support staff aware that all additional changes must be recorded and the updates noted in the inventory.
|
||||
|
||||
This inventory will be critical for planning and implementing your Windows Firewall with Advanced Security design.
|
||||
|
||||
**Next: **[Gathering Other Relevant Information](gathering-other-relevant-information.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,11 +2,18 @@
|
||||
title: Gathering Information about Your Current Network Infrastructure (Windows 10)
|
||||
description: Gathering Information about Your Current Network Infrastructure
|
||||
ms.assetid: f98d2b17-e71d-4ffc-b076-118b4d4782f9
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Gathering Information about Your Current Network Infrastructure
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
Perhaps the most important aspect of planning for Windows Firewall with Advanced Security deployment is the network architecture, because IPsec is layered on the Internet Protocol itself. An incomplete or inaccurate understanding of the network can prevent any Windows Firewall with Advanced Security solution from being successful. Understanding subnet layout, IP addressing schemes, and traffic patterns are part of this effort, but accurately documenting the following components are important to completing the planning phase of this project:
|
||||
|
||||
@ -14,7 +21,7 @@ Perhaps the most important aspect of planning for Windows Firewall with Advanced
|
||||
|
||||
- Network address translation (NAT). NAT is a means of separating network segments by using a device that maps all of the IP addresses on one side of the device to a single IP address accessible on the other side.
|
||||
|
||||
- Network infrastructure devices. This includes the routers, switches, hubs, and other network equipment that makes communications between the computers on the network possible.
|
||||
- Network infrastructure devices. This includes the routers, switches, hubs, and other network equipment that makes communications between the devices on the network possible.
|
||||
|
||||
- **Current network traffic model.** This includes the quantity and the characteristics of the network traffic flowing through your network.
|
||||
|
||||
@ -35,7 +42,7 @@ If your organization does not have its current network architecture documented a
|
||||
|
||||
- Undertake a discovery project, either through manual processes or with network analysis tools that can provide the information you need to document the current network topology.
|
||||
|
||||
Although the required information can be presented in many different ways, a series of schematic diagrams is often the most effective method of illustrating and understanding the current network configuration. When creating network diagrams, do not include too much information. If necessary, use multiple diagrams that show different layers of detail. Use a top-level diagram that illustrates the major sites that make up your organization's network, and then break out each site into a more detailed diagram that captures a deeper level of detail. Continue until you reach the individual IP subnet level, and so have the means to identify the network location of every computer in your organization.
|
||||
Although the required information can be presented in many different ways, a series of schematic diagrams is often the most effective method of illustrating and understanding the current network configuration. When creating network diagrams, do not include too much information. If necessary, use multiple diagrams that show different layers of detail. Use a top-level diagram that illustrates the major sites that make up your organization's network, and then break out each site into a more detailed diagram that captures a deeper level of detail. Continue until you reach the individual IP subnet level, and so have the means to identify the network location of every device in your organization.
|
||||
|
||||
During this process, you might discover some network applications and services that are not compatible with IPsec. For example, IPsec breaks network-based prioritization and port/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.
|
||||
|
||||
@ -53,23 +60,14 @@ Other examples of incompatibility include:
|
||||
|
||||
- Network monitoring tools might be unable to parse ESP packets that are not encrypted (ESP-Null).
|
||||
|
||||
**Note**
|
||||
Network Monitor added an ESP parser starting in version 2.1 to aid troubleshooting of unencrypted IPsec packets. The latest version of Network Monitor is available as a free download from Microsoft (<http://go.microsoft.com/fwlink/?linkid=94770>).
|
||||
|
||||
>**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](http://www.microsoft.com/download/details.aspx?id=44226).
|
||||
|
||||
|
||||
## 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 does not support the use of AH across NAT devices.
|
||||
|
||||
IPsec NAT-T is supported by Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, Windows Server 2008 R2,
|
||||
|
||||
For detailed information about how IPsec NAT-T works, see "IPsec NAT Traversal Overview" in the August 2002 Cable Guy article at <http://go.microsoft.com/fwlink/?LinkId=45080>.
|
||||
|
||||
## 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.
|
||||
@ -86,10 +84,7 @@ The devices that make up the network infrastructure (routers, switches, load bal
|
||||
|
||||
- **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.
|
||||
|
||||
|
||||
>**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 does not have such a parser, it cannot determine if data in those packets is encrypted.
|
||||
|
||||
@ -97,32 +92,22 @@ After you obtain this information, you can quickly determine whether you must up
|
||||
|
||||
## Current network traffic model
|
||||
|
||||
|
||||
After gathering the addressing and network infrastructure information, the next step is to examine the communications flow. For example, if a department such as Human Resources (HR) spans several buildings, and you want to use server isolation with encryption to help protect information in that department, you must know how those buildings are connected to determine the level of "trust" to place in the connection. A highly secured building that is connected by an unprotected cable to another building that is not secured can be compromised by an eavesdropping or information replay attack. If such an attack is considered a threat, IPsec can help by providing 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. This includes non-Windows-based computers running Linux, UNIX, and Macintosh. Ask yourself such questions as:
|
||||
When you examine traffic flow, look closely at how all managed and unmanaged devices interact. This includes 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 Firewall on your computers to "lock down" specific ports, such as UDP 500, IKE negotiations fail.
|
||||
- Are there security devices or projects currently implemented or planned that could affect an isolation deployment? For example, if you use Windows Firewall on your 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 is common to have ports 137, 138, and 139 enabled for NetBT and port 445 enabled for SMB. These ports provide NetBIOS name resolution services and other features. Unfortunately, they also allow the creation of *null sessions*. A null session is a session that is established on a host that does not use the security context of a known user or entity. Frequently, these sessions are anonymous.
|
||||
|
||||
- **Remote procedure call (RPC)**. RPC operates by listening on a port known as the *endpoint mapper*, TCP port 135. The response to a query on this port is an instruction to begin communication on another port in the ephemeral range (ports numbered over 1024). In a network that is segmented by firewalls, RPC communication presents a configuration challenge because it means opening the RPC listener port and all ports greater than 1024. Opening so many ports increases the attack surface of the whole network and reduces the effectiveness of the firewalls. Computers running Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2 reduce this risk by introducing stateful inspection of RPC traffic. Because many applications depend on RPC for basic functionality, any firewall and connection security policy must take RPC requirements into account.
|
||||
- **Remote procedure call (RPC)**. RPC operates by listening on a port known as the *endpoint mapper*, TCP port 135. The response to a query on this port is an instruction to begin communication on another port in the ephemeral range (ports numbered over 1024). In a network that is segmented by firewalls, RPC communication presents a configuration challenge because it means opening the RPC listener port and all ports greater than 1024. Opening so many ports increases the attack surface of the whole network and reduces the effectiveness of the firewalls. Because many applications depend on RPC for basic functionality, any firewall and connection security policy must take RPC requirements into account.
|
||||
|
||||
- **Other traffic**. Windows Firewall with Advanced Security can help secure transmissions between computers by providing authentication of the packets in addition to encrypting the data that they contain. The important thing to do is to identify what must be protected, and the threats that must be mitigated. Examine and model other traffic or traffic types that must be secured.
|
||||
- **Other traffic**. Windows Firewall with Advanced Security 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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,20 +2,26 @@
|
||||
title: Gathering Other Relevant Information (Windows 10)
|
||||
description: Gathering Other Relevant Information
|
||||
ms.assetid: 87ccca07-4346-496b-876d-cdde57d0ce17
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Gathering Other Relevant Information
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
This topic discusses several other things that you should examine to see whether they will cause any complications in your ability to deploy Windows Firewall with Advanced Security policies in your organization.
|
||||
|
||||
## Capacity considerations
|
||||
|
||||
Because IPsec uses mathematically intensive cryptographic techniques, it can consume significant overhead on a device. Areas to watch:
|
||||
|
||||
Because IPsec uses mathematically intensive cryptographic techniques, it can consume significant overhead on a computer. Areas to watch:
|
||||
|
||||
- **Encryption.** You might use 256-bit Advanced Encryption Standard (AES-256) and 384-bit Secure Hash Algorithm (SHA-384) to check integrity in situations that require the strongest available encryption and key exchange protection. 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](http://technet.microsoft.com/network/dd277647.aspx) at http://technet.microsoft.com/network/dd277647.aspx
|
||||
- **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](http://technet.microsoft.com/network/dd277647.aspx).
|
||||
|
||||
- **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.
|
||||
|
||||
@ -25,26 +31,19 @@ Because IPsec uses mathematically intensive cryptographic techniques, it can con
|
||||
|
||||
- **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.
|
||||
|
||||
|
||||
>**Note:** When Microsoft deployed its own domain isolation solution, it found a one to three percent increase in usage on the network as a direct result of IPsec.
|
||||
|
||||
## Group Policy deployment groups and WMI filters
|
||||
|
||||
|
||||
You do not have to rearrange the organization unit (OU) hierarchy of your Active Directory domains to effectively deploy Windows Firewall with Advanced Security GPOs. Instead, you can link your GPOs at the domain level (or another high level container), and then use security group filtering or WMI filtering to ensure that only the appropriate computers or users can apply the GPO settings. Because the firewall and connection security rules have evolved significantly from Windows 2000 Server to Windows XP and Windows Server 2003, and now with Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2, we recommend that you use WMI filtering to dynamically ensure that GPOs apply only to computers that are running the correct operating system. It is not necessary to use this technique if your network consists of computers running Windows Vista or later.
|
||||
You do not have to rearrange the organization unit (OU) hierarchy of your Active Directory domains to effectively deploy Windows Firewall with Advanced Security GPOs. Instead, you can link your GPOs at the domain level (or another high level container), and then use security group filtering or WMI filtering to ensure that only the appropriate 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 is 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 responder’s domain. If firewalls separate the domains then you must configure the firewall to allow Kerberos V5 traffic over UDP destination port 88, TCP destination port 88, and UDP destination port 389.
|
||||
|
||||
For more information, see "Active Directory in Networks Segmented by Firewalls" at <http://go.microsoft.com/fwlink/?LinkId=45087>.
|
||||
|
||||
If the use of Kerberos V5 authentication is not possible because two-way trusts across forests cannot be established as in some large enterprise environments, you can use a public key infrastructure (PKI) and digital certificates to establish IPsec-trusted communication. For an example of how Microsoft deployed their PKI, see "Deploying PKI Inside Microsoft" at <http://go.microsoft.com/fwlink/?LinkId=45088>.
|
||||
If the use of Kerberos V5 authentication is not possible because two-way trusts across forests cannot be established as in some large enterprise environments, you can use a public key infrastructure (PKI) and digital certificates to establish IPsec-trusted communication.
|
||||
|
||||
## Creating firewall rules to permit IKE, AH, and ESP traffic
|
||||
|
||||
@ -53,39 +52,26 @@ In some cases, IPsec-secured traffic might have to pass through a router, perime
|
||||
|
||||
In the case of a filtering router or a firewall, you must configure these devices to allow IPsec traffic to be forwarded. Configure the firewall to allow IPsec traffic on UDP source and destination port 500 (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.
|
||||
|
||||
For more information, see "How to Enable IPsec Traffic Through a Firewall" at <http://go.microsoft.com/fwlink/?LinkId=45085>.
|
||||
For more info, see [How to Enable IPsec Traffic Through a Firewall](http://go.microsoft.com/fwlink/?LinkId=45085).
|
||||
|
||||
## Network load balancing and server clusters
|
||||
|
||||
|
||||
There are challenges implementing connection security for network traffic going to and from network load balancing (NLB) clusters and server clusters. NLB enables multiple servers to be clustered together to provide high availability for a service by providing automatic failover to other nodes in the cluster. Because IPsec matches a security association to a specific computer, it prevents different computers from handling the same client connection. If a different node in the cluster responds to an IPsec connection that was originally established by another node, the traffic will be dropped by the client computer as untrusted.
|
||||
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 means that NLB in "no affinity" mode is not supported by IPsec at all. If you must use "no affinity" mode in the cluster then consider including the servers that make up the cluster in your IPsec exemption group, and allowing clients to communicate with the servers without IPsec.
|
||||
|
||||
**IPsec improvements for clusters running Windows Server 2008**
|
||||
|
||||
Starting with Windows Server 2008 and Windows Vista, IPsec is much more tightly integrated into TCP/IP than in earlier versions of Windows. When a TCP connection is dropped because of a cluster node failover, IPsec on a computer that is running Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2 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.
|
||||
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 are not yet compatible. Check with the vendor of your device to see whether the changes in the protocol and port fields caused by IPsec are compatible with the device.
|
||||
|
||||
Any device designed to view network traffic, such as hardware protocol analyzers or Microsoft Network Monitor, cannot parse ESP-encrypted traffic. Only the destination computer, with which the originating computer negotiated the connection, can decrypt the traffic.
|
||||
Any device designed to view network traffic, such as hardware protocol analyzers or Microsoft Network Monitor, cannot 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 is no workaround; the host itself must handle any traffic management functions. For unencrypted, authenticated-only packets, the devices and applications must be aware of how IPsec changes packets to be able to do anything with them other than route them to the correct host. If you cannot upgrade monitoring or management devices to support IPsec, it is important that you record this information and figure it into your domain or server isolation design.
|
||||
|
||||
Network Monitor includes parsers for the ISAKMP (IKE), AH, and ESP protocols. Network Monitor parsers for ESP can parse inside the ESP packet only if ESP null-encryption is being used. Network Monitor cannot parse the encrypted parts of IPsec ESP traffic when encryption is performed in software. However, if encryption is performed by an IPsec hardware offload network adapter, the ESP packets can be decrypted when Network Monitor captures them on either the source or the destination and, therefore, they can be parsed. To diagnose ESP software-encrypted communication, you must disable ESP encryption and use ESP-null encryption by changing the IPsec policy or connection security rule on both computers.
|
||||
|
||||
Network Monitor is available as a free download from Microsoft at <http://go.microsoft.com/fwlink/?linkid=94770>.
|
||||
|
||||
**Next: **[Determining the Trusted State of Your Computers](determining-the-trusted-state-of-your-computers.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Monitor includes parsers for the ISAKMP (IKE), AH, and ESP protocols. Network Monitor parsers for ESP can parse inside the ESP packet only if ESP null-encryption is being used. Network Monitor cannot parse the encrypted parts of IPsec ESP traffic when encryption is performed in software. However, if encryption is performed by an IPsec hardware offload network adapter, the ESP packets can be decrypted when Network Monitor captures them on either the source or the destination and, therefore, they can be parsed. To diagnose ESP 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](https://www.microsoft.com/download/details.aspx?id=44226).
|
||||
|
||||
**Next: **[Determining the Trusted State of Your Devices](determining-the-trusted-state-of-your-devices.md)
|
||||
|
@ -2,13 +2,20 @@
|
||||
title: Gathering the Information You Need (Windows 10)
|
||||
description: Gathering the Information You Need
|
||||
ms.assetid: 545fef02-5725-4b1e-b67a-a32d94c27d15
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Gathering the Information You Need
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
Before starting the planning process for a Windows Firewall with Advanced Security deployment, you must collect and analyze up-to-date information about the network, the directory services, and the computers that are already deployed in the organization. This information enables you to create a design that accounts for all possible elements of the existing infrastructure. If the gathered information is not accurate, problems can occur when devices and computers that were not considered during the planning phase are encountered during implementation.
|
||||
Before starting the planning process for a Windows Firewall with Advanced Security deployment, you must collect and analyze up-to-date information about the network, the directory services, and the 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 is not accurate, problems can occur when devices and devices that were not considered during the planning phase are encountered during implementation.
|
||||
|
||||
Review each of the following topics for guidance about the kinds of information that you must gather:
|
||||
|
||||
@ -16,15 +23,6 @@ Review each of the following topics for guidance about the kinds of information
|
||||
|
||||
- [Gathering Information about Your Active Directory Deployment](gathering-information-about-your-active-directory-deployment.md)
|
||||
|
||||
- [Gathering Information about Your Computers](gathering-information-about-your-computers.md)
|
||||
- [Gathering Information about Your Devices](gathering-information-about-your-devices.md)
|
||||
|
||||
- [Gathering Other Relevant Information](gathering-other-relevant-information.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -6,7 +6,6 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
@ -58,6 +57,4 @@ The following table lists the three main tasks for articulating, refining, and s
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
**Next:** [Protect Computers from Unwanted Network Traffic](protect-computers-from-unwanted-network-traffic.md)
|
||||
|
@ -2,81 +2,32 @@
|
||||
title: Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design (Windows 10)
|
||||
description: Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design
|
||||
ms.assetid: 7e68c59e-ba40-49c4-8e47-5de5d6b5eb22
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
After you finish reviewing the existing Windows Firewall with Advanced Security deployment goals and you determine which goals are important to your specific deployment, you can map those goals to a specific Windows Firewall with Advanced Security design.
|
||||
|
||||
**Important**
|
||||
The first three designs presented in this guide build on each other to progress from simpler to more complex. Therefore during deployment, consider implementing them in the order presented. Each deployed design also provides a stable position from which to evaluate your progress, and to make sure that your goals are being met before you continue to the next design.
|
||||
|
||||
|
||||
>**Important:** The first three designs presented in this guide build on each other to progress from simpler to more complex. Therefore during deployment, consider implementing them in the order presented. Each deployed design also provides a stable position from which to evaluate your progress, and to make sure that your goals are being met before you continue to the next design.
|
||||
|
||||
Use the following table to determine which Windows Firewall with Advanced Security design maps to the appropriate combination of Windows Firewall with Advanced Security deployment goals for your organization. This table refers only to the Windows Firewall with Advanced Security designs as described in this guide. However, you can create a hybrid or custom Windows Firewall with Advanced Security design by using any combination of the Windows Firewall with Advanced Security deployment goals to meet the needs of your organization.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="20%" />
|
||||
<col width="20%" />
|
||||
<col width="20%" />
|
||||
<col width="20%" />
|
||||
<col width="20%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th>Deployment Goals</th>
|
||||
<th>[Basic Firewall Policy Design](basic-firewall-policy-design.md)</th>
|
||||
<th>[Domain Isolation Policy Design](domain-isolation-policy-design.md)</th>
|
||||
<th>[Server Isolation Policy Design](server-isolation-policy-design.md)</th>
|
||||
<th>[Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md)</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td><p>[Protect Computers from Unwanted Network Traffic](protect-computers-from-unwanted-network-traffic.md)</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td><p>[Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md)</p></td>
|
||||
<td><p>-</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td><p>[Restrict Access to Only Specified Users or Computers](restrict-access-to-only-specified-users-or-computers.md)</p></td>
|
||||
<td><p>-</p></td>
|
||||
<td><p>-</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
<td><p>Yes</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td><p>[Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)</p></td>
|
||||
<td><p>-</p></td>
|
||||
<td><p>Optional</p></td>
|
||||
<td><p>Optional</p></td>
|
||||
<td><p>Optional</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
| Deployment Goals | Basic Firewall Policy Design | Domain Isolation Policy Design | Server Isolation Policy Design | Certificate-based Isolation Policy Design |
|
||||
| - |- | - | - | - |
|
||||
| [Protect Computers from Unwanted Network Traffic](protect-computers-from-unwanted-network-traffic.md)| Yes| Yes| Yes| Yes|
|
||||
| [Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md) | -| Yes| Yes| Yes|
|
||||
| [Restrict Access to Only Specified Users or Computers](restrict-access-to-only-specified-users-or-computers.md)| -| -| Yes| Yes|
|
||||
| [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)| -| Optional| Optional| Optional|
|
||||
|
||||
To examine details for a specific design, click the design title at the top of the column in the preceding table.
|
||||
|
||||
**Next: **[Basic Firewall Policy Design](basic-firewall-policy-design.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Protect Computers from Unwanted Network Traffic (Windows 10)
|
||||
description: Protect Computers from Unwanted Network Traffic
|
||||
ms.assetid: 307d2b38-e8c4-4358-ae16-f2143af965dc
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Protect Computers from Unwanted Network Traffic
|
||||
|
||||
|
||||
Although network perimeter firewalls provide important protection to network resources from external threats, there are network threats that a perimeter firewall cannot protect against. Some attacks might successfully penetrate the perimeter firewall, and at that point what can stop it? Other attacks might originate from inside the network, such as a computer virus that is brought in on portable media and run on a trusted computer. Portable computers are often taken outside the network and connected directly to the Internet, without adequate protection between the computer and security threats.
|
||||
|
||||
Reports of targeted attacks against organizations, governments, and individuals have become more widespread in recent years. For a general overview of these threats, also known as advanced persistent threats (APT), see the [Microsoft Security Intelligence Report](http://download.microsoft.com/download/C/9/A/C9A544AD-4150-43D3-80F7-4F1641EF910A/Microsoft_Security_Intelligence_Report_Volume_12_Key_Findings_Summary_English.pdf) at http://download.microsoft.com/download/C/9/A/C9A544AD-4150-43D3-80F7-4F1641EF910A/Microsoft\_Security\_Intelligence\_Report\_Volume\_12\_Key\_Findings\_Summary\_English.pdf.
|
||||
|
||||
Running a host-based firewall on every computer that your organization manages is an important layer in a "defense-in-depth" security strategy. A host-based firewall can help protect against attacks that originate from inside the network and also provide additional protection against attacks from outside the network that manage to penetrate the perimeter firewall. It also travels with a portable computer to provide protection when it is away from the organization's network.
|
||||
|
||||
A host-based firewall helps secure a computer by dropping all network traffic that does not match the administrator-designed rule set for permitted network traffic. This design, which corresponds to [Basic Firewall Policy Design](basic-firewall-policy-design.md), provides the following benefits:
|
||||
|
||||
- Network traffic that is a reply to a request from the local computer is permitted into the computer from the network.
|
||||
|
||||
- Network traffic that is unsolicited, but that matches a rule for allowed network traffic, is permitted into the computer from the network.
|
||||
|
||||
For example, Woodgrove Bank wants a computer that is running SQL Server to be able to receive the SQL queries sent to it by client computers. The firewall policy deployed to the computer that is running SQL Server includes firewall rules that specifically allow inbound network traffic for the SQL Server program.
|
||||
|
||||
- Outbound network traffic that is not specifically blocked is allowed on the network.
|
||||
|
||||
For example, Woodgrove Bank has a corporate policy that prohibits the use of certain peer-to-peer file sharing programs. The firewall policy deployed to the computers on the network includes firewall rules that block both inbound and outbound network traffic for the prohibited programs. All other outbound traffic is permitted.
|
||||
|
||||
The following component is recommended for this deployment goal:
|
||||
|
||||
- **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more Group Policy objects (GPOs) that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see [Additional Resources](additional-resources-wfasdesign.md).
|
||||
|
||||
Other means of deploying a firewall policy are available, such as creating scripts that use the **netsh** command-line tool, and then running those scripts on each computer in the organization. This guide uses Active Directory as a recommended means of deployment because of its ability to scale to very large organizations.
|
||||
|
||||
**Next: **[Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,15 +2,22 @@
|
||||
title: Require Encryption When Accessing Sensitive Network Resources (Windows 10)
|
||||
description: Require Encryption When Accessing Sensitive Network Resources
|
||||
ms.assetid: da980d30-a68b-4e2a-ba63-94726355ce6f
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Require Encryption When Accessing Sensitive Network Resources
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
The use of authentication in the previously described goal ([Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md)) enables a computer in the isolated domain to block traffic from untrusted computers. However, it does not prevent an untrusted computer from eavesdropping on the network traffic shared between two trusted computers, because by default network packets are not encrypted.
|
||||
The use of authentication in the previously described goal ([Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md)) enables a device in the isolated domain to block traffic from untrusted devices. However, it does not prevent an untrusted device from eavesdropping on the network traffic shared between two trusted devices, because by default network packets are not encrypted.
|
||||
|
||||
For computers that share sensitive information over the network, Windows Firewall with Advanced Security allows you to require that all such network traffic be encrypted. Using encryption can help you comply with regulatory and legislative requirements such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations. By creating connection security rules that apply to computers that host and exchange sensitive data, you can help protect the confidentiality of that data by encrypting it.
|
||||
For devices that share sensitive information over the network, Windows Firewall with Advanced Security allows you to require that all such network traffic be encrypted. Using encryption can help you comply with regulatory and legislative requirements such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations. By creating connection security rules that apply to devices that host and exchange sensitive data, you can help protect the confidentiality of that data by encrypting it.
|
||||
|
||||
The following illustration shows an encryption zone in an isolated domain. The rules that implement both the isolated domain and the different zones are deployed by using Group Policy and Active Directory.
|
||||
|
||||
@ -18,25 +25,16 @@ The following illustration shows an encryption zone in an isolated domain. The r
|
||||
|
||||
This goal provides the following benefits:
|
||||
|
||||
- Computers in the encryption zone require authentication to communicate with other computers. This works no differently from the domain isolation goal and design. For more information, see [Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md).
|
||||
- Devices in the encryption zone require authentication to communicate with other devices. This works no differently from the domain isolation goal and design. For more info, see [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md).
|
||||
|
||||
- Computers in the encryption zone require that all inbound and outbound network traffic be encrypted.
|
||||
- Devices in the encryption zone require that all inbound and outbound network traffic be encrypted.
|
||||
|
||||
For example, Woodgrove Bank processes sensitive customer data on a computer that must be protected from eavesdropping by computers on the network. Connection security rules specify that all traffic must be encrypted by a sufficiently complex encryption algorithm to help protect the data.
|
||||
For example, Woodgrove Bank processes sensitive customer data on a device that must be protected from eavesdropping by devices on the network. Connection security rules specify that all traffic must be encrypted by a sufficiently complex encryption algorithm to help protect the data.
|
||||
|
||||
- Computers in the encryption zone are often good candidates for server isolation, where access is limited to only computer accounts and user accounts that are members of an authorized access group. In many organizations, the encryption zone and the server isolation zone are one and the same. For more information, see [Restrict Access to Only Specified Users or Computers](restrict-access-to-only-specified-users-or-computers.md).
|
||||
- Devices in the encryption zone are often good candidates for server isolation, where access is limited to only computer accounts and user accounts that are members of an authorized access group. In many organizations, the encryption zone and the server isolation zone are one and the same. For more info, see [Restrict Access to Only Specified Users or Devices](restrict-access-to-only-specified-users-or-devices.md).
|
||||
|
||||
The following components are required for this deployment goal:
|
||||
|
||||
- **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see [Additional Resources](additional-resources-wfasdesign.md).
|
||||
|
||||
**Next: **[Restrict Access to Only Specified Users or Computers](restrict-access-to-only-specified-users-or-computers.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant devices in the domain. For more info about Active Directory, see [Additional Resources](additional-resources-wfasdesign.md).
|
||||
|
||||
**Next: **[Restrict Access to Only Specified Users or Devices](restrict-access-to-only-specified-users-or-devices.md)
|
||||
|
@ -1,46 +0,0 @@
|
||||
---
|
||||
title: Restrict Access to Only Specified Users or Computers (Windows 10)
|
||||
description: Restrict Access to Only Specified Users or Computers
|
||||
ms.assetid: a6106a07-f9e5-430f-8dbd-06d3bf7406df
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Restrict Access to Only Specified Users or Computers
|
||||
|
||||
|
||||
Domain isolation (as described in the previous goal [Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md)) prevents computers that are members of the isolated domain from accepting network traffic from untrusted computers. However, some computers on the network might host sensitive data that must be additionally restricted to only those users and computers that have a business requirement to access the data.
|
||||
|
||||
Windows Firewall with Advanced Security enables you to restrict access to computers and users that are members of domain groups authorized to access that computer. These groups are called *network access groups (NAGs)*. When a computer authenticates to a server, the server checks the group membership of the computer account and the user account, and grants access only if membership in the NAG is confirmed. Adding this check creates a virtual "secure zone" within the domain isolation zone. You can have multiple computers in a single secure zone, and it is likely that you will create a separate zone for each set of servers that have specific security access needs. Computers that are part of this server isolation zone are often also part of the encryption zone (see [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)).
|
||||
|
||||
Restricting access to only users and computers that have a business requirement can help you comply with regulatory and legislative requirements, such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations.
|
||||
|
||||
Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows Vista enable you to restrict access by specifying either computer or user credentials.
|
||||
|
||||
The following illustration shows an isolated server, and examples of computers that can and cannot communicate with it. Computers that are outside the Woodgrove corporate network, or computers that are in the isolated domain but are not members of the required NAG, cannot communicate with the isolated server.
|
||||
|
||||

|
||||
|
||||
This goal, which corresponds to [Server Isolation Policy Design](server-isolation-policy-design.md), provides the following features:
|
||||
|
||||
- Isolated servers accept unsolicited inbound network traffic only from computers or users that are members of the NAG.
|
||||
|
||||
- Isolated servers can be implemented as part of an isolated domain, and treated as another zone. Members of the zone group receive a GPO with rules that require authentication, and that specify that only network traffic authenticated as coming from a member of the NAG is allowed.
|
||||
|
||||
- Server isolation can also be configured independently of an isolated domain. To do so, configure only the computers that must communicate with the isolated server with connection security rules to implement authentication and check NAG membership.
|
||||
|
||||
- A server isolation zone can be simultaneously configured as an encryption zone. To do this, configure the GPO with rules that force encryption in addition to requiring authentication and restricting access to NAG members. For more information, see [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
|
||||
|
||||
The following components are required for this deployment goal:
|
||||
|
||||
- **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see [Additional Resources](additional-resources-wfasdesign.md).
|
||||
|
||||
**Next: **[Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design](mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -1,59 +0,0 @@
|
||||
---
|
||||
title: Restrict Access to Only Trusted Computers (Windows 10)
|
||||
description: Restrict Access to Only Trusted Computers
|
||||
ms.assetid: bc1f49a4-7d54-4857-8af9-b7c79f47273b
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Restrict Access to Only Trusted Computers
|
||||
|
||||
|
||||
Your organizational network likely has a connection to the Internet. You also likely have partners, vendors, or contractors who attach computers that are not owned by your organization to your network. Because you do not manage those computers, you cannot trust them to be free of malicious software, maintained with the latest security updates, or in any way in compliance with your organization's security policies. These untrustworthy computers both on and outside of your physical network must not be permitted to access your organization's computers except where it is truly required.
|
||||
|
||||
To mitigate this risk, you must be able to isolate the computers you trust, and restrict their ability to receive unsolicited network traffic from untrusted computers. By using connection security and firewall rules available in Windows Firewall with Advanced Security, you can logically isolate the computers that you trust by requiring that all unsolicited inbound network traffic be authenticated. Authentication ensures that each computer or user can positively identify itself by using credentials that are trusted by the other computer. Connection security rules can be configured to use IPsec with the Kerberos V5 protocol available in Active Directory, or certificates issued by a trusted certification authority as the authentication method.
|
||||
|
||||
**Note**
|
||||
Because the primary authentication method recommended for computers that are running Windows is to use the Kerberos V5 protocol with membership in an Active Directory domain, this guide refers to this logical separation of computers as *domain isolation*, even when certificates are used to extend the protection to computers that are not part of an Active Directory domain.
|
||||
|
||||
|
||||
|
||||
The protection provided by domain isolation can help you comply with regulatory and legislative requirements, such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations.
|
||||
|
||||
The following illustration shows an isolated domain, with one of the zones that are optionally part of the design. The rules that implement both the isolated domain and the different zones are deployed by using Group Policy and Active Directory.
|
||||
|
||||

|
||||
|
||||
These goals, which correspond to [Domain Isolation Policy Design](domain-isolation-policy-design.md) and [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md), provide the following benefits:
|
||||
|
||||
- Computers in the isolated domain accept unsolicited inbound network traffic only when it can be authenticated as coming from another computer in the isolated domain. Exemption rules can be defined to allow inbound traffic from trusted computers that for some reason cannot perform IPsec authentication.
|
||||
|
||||
For example, Woodgrove Bank wants all of its computers to block all unsolicited inbound network traffic from any computer that it does not manage. The connection security rules deployed to domain member computers require authentication as a domain member or by using a certificate before an unsolicited inbound network packet is accepted.
|
||||
|
||||
- Computers in the isolated domain can still send outbound network traffic to untrusted computers and receive the responses to the outbound requests.
|
||||
|
||||
For example, Woodgrove Bank wants its users at client computers to be able to access Web sites on the Internet. The default Windows Firewall with Advanced Security settings for outbound network traffic allow this. No additional rules are required.
|
||||
|
||||
These goals also support optional zones that can be created to add customized protection to meet the needs of subsets of an organization's computers:
|
||||
|
||||
- Computers in the "boundary zone" are configured to use connection security rules that request but do not require authentication. This enables them to receive unsolicited inbound network traffic from untrusted computers, and also to receive traffic from the other members of the isolated domain.
|
||||
|
||||
For example, Woodgrove Bank has a server that must be accessed by its partners' computers through the Internet. The rules applied to computers in the boundary zone use authentication when the client computer can support it, but do not block the connection if the client computer cannot authenticate.
|
||||
|
||||
- Computers in the "encryption zone" require that all network traffic in and out must be encrypted to secure potentially sensitive material when it is sent over the network.
|
||||
|
||||
For example, Woodgrove Bank wants the computers running SQL Server to only transmit data that is encrypted to help protect the sensitive data stored on those computers.
|
||||
|
||||
The following components are required for this deployment goal:
|
||||
|
||||
- **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see [Additional Resources](additional-resources-wfasdesign.md).
|
||||
|
||||
**Next: **[Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -1,189 +0,0 @@
|
||||
---
|
||||
title: Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012 (Windows 10)
|
||||
description: Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Securing End-to-End IPsec connections by using IKEv2
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
IKEv2 offers the following:
|
||||
|
||||
- Supports IPsec end-to-end transport mode connections
|
||||
|
||||
- Provides interoperability for Windows with other operating systems that use IKEv2 for end-to-end security
|
||||
|
||||
- Supports Suite B (RFC 4869) requirements
|
||||
|
||||
- Coexists with existing policies that deploy AuthIP/IKEv1
|
||||
|
||||
- Uses the Windows PowerShell interface exclusively for configuration. You cannot configure IKEv2 through the user interface.
|
||||
|
||||
- Uses certificates for the authentication mechanism
|
||||
|
||||
You can use IKEv2 as a virtual private network (VPN) tunneling protocol that supports automatic VPN reconnection. IKEv2 allows the security association to remain unchanged despite changes in the underlying connection.
|
||||
|
||||
**In this document**
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
|
||||
- [Devices joined to a domain](#devices-joined-to-a-domain)
|
||||
|
||||
- [Device not joined to a domain](#devices-not-joined-to-a-domain)
|
||||
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
|
||||
>**Note:** This topic includes sample Windows PowerShell cmdlets. For more info, see [How to Run a Windows PowerShell Cmdlet](http://go.microsoft.com/fwlink/p/?linkid=230693).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
These procedures assume that you already have a public key infrastructure (PKI) in place for device authentication.
|
||||
|
||||
## Devices joined to a domain
|
||||
|
||||
The following Windows PowerShell script establishes a connection security rule that uses IKEv2 for communication between two computers (CLIENT1 and SERVER1) that are joined to the corp.contoso.com domain as shown in Figure 1.
|
||||
|
||||

|
||||
|
||||
**Figure 1** The Contoso corporate network
|
||||
|
||||
This script does the following:
|
||||
|
||||
- Creates a security group called **IPsec client and servers** and adds CLIENT1 and SERVER1 as members.
|
||||
|
||||
- Creates a Group Policy Object (GPO) called **IPsecRequireInRequestOut** and links it to the corp.contoso.com domain.
|
||||
|
||||
- Sets the permissions to the GPO so that they apply only to the computers in **IPsec client and servers** and not to **Authenticated Users**.
|
||||
|
||||
- Indicates the certificate to use for authentication.
|
||||
|
||||
>**Important:** The certificate parameters that you specify for the certificate are case sensitive, so make sure that you type them exactly as specified in the certificate, and place the parameters in the exact order that you see in the following example. Failure to do so will result in connection errors.
|
||||
|
||||
- Creates the IKEv2 connection security rule called **My IKEv2 Rule**.
|
||||
|
||||
**Windows PowerShell commands**
|
||||
|
||||
Type each cmdlet on a single line, even though they may appear to wrap across several lines because of formatting constraints.
|
||||
|
||||
``` syntax
|
||||
# Create a Security Group for the computers that will get the policy
|
||||
$pathname = (Get-ADDomain).distinguishedname
|
||||
New-ADGroup -name "IPsec client and servers" -SamAccountName "IPsec client and servers" `
|
||||
-GroupCategory security -GroupScope Global -path $pathname
|
||||
|
||||
# Add test computers to the Security Group
|
||||
$computer = Get-ADComputer -LDAPFilter "(name=client1)"
|
||||
Add-ADGroupMember -Identity "IPsec client and servers" -Members $computer
|
||||
$computer = Get-ADComputer -LDAPFilter "(name=server1)"
|
||||
Add-ADGroupMember -Identity "IPsec client and servers" -Members $computer
|
||||
|
||||
# Create and link the GPO to the domain
|
||||
$gpo = New-gpo IPsecRequireInRequestOut
|
||||
$gpo | new-gplink -target "dc=corp,dc=contoso,dc=com" -LinkEnabled Yes
|
||||
|
||||
# Set permissions to security group for the GPO
|
||||
$gpo | Set-GPPermissions -TargetName "IPsec client and servers" -TargetType Group -PermissionLevel GpoApply -Replace
|
||||
$gpo | Set-GPPermissions -TargetName "Authenticated Users" -TargetType Group -PermissionLevel None -Replace
|
||||
|
||||
#Set up the certificate for authentication
|
||||
$gponame = "corp.contoso.com\IPsecRequireInRequestOut"
|
||||
$certprop = New-NetIPsecAuthProposal -machine -cert -Authority "DC=com, DC=contoso, DC=corp, CN=corp-APP1-CA"
|
||||
$myauth = New-NetIPsecPhase1AuthSet -DisplayName "IKEv2TestPhase1AuthSet" -proposal $certprop –PolicyStore GPO:$gponame
|
||||
|
||||
#Create the IKEv2 Connection Security rule
|
||||
New-NetIPsecRule -DisplayName "My IKEv2 Rule" -RemoteAddress any -Phase1AuthSet $myauth.InstanceID `
|
||||
-InboundSecurity Require -OutboundSecurity Request -KeyModule IKEv2 -PolicyStore GPO:$gponame
|
||||
```
|
||||
|
||||
## Devices not joined to a domain
|
||||
|
||||
Use a Windows PowerShell script similar to the following to create a local IPsec policy on the devices that you want to include in the secure connection.
|
||||
|
||||
>**Important:** The certificate parameters that you specify for the certificate are case sensitive, so make sure that you type them exactly as specified in the certificate, and place the parameters in the exact order that you see in the following example. Failure to do so will result in connection errors.
|
||||
|
||||
**Windows PowerShell commands**
|
||||
|
||||
Type each cmdlet on a single line, even though they may appear to wrap across several lines because of formatting constraints.
|
||||
|
||||
``` syntax
|
||||
#Set up the certificate
|
||||
$certprop = New-NetIPsecAuthProposal -machine -cert -Authority "DC=com, DC=contoso, DC=corp, CN=corp-APP1-CA"
|
||||
$myauth = New-NetIPsecPhase1AuthSet -DisplayName "IKEv2TestPhase1AuthSet" -proposal $certprop
|
||||
|
||||
#Create the IKEv2 Connection Security rule
|
||||
New-NetIPsecRule -DisplayName "My IKEv2 Rule" -RemoteAddress any -Phase1AuthSet $myauth.InstanceID `
|
||||
-InboundSecurity Require -OutboundSecurity Request -KeyModule IKEv2
|
||||
```
|
||||
|
||||
Make sure that you install the required certificates on the participating computers.
|
||||
|
||||
>**Note:**
|
||||
- For local devices, you can import the certificates manually if you have administrator access to the computer. For more info, see [Import or export certificates and private keys](http://windows.microsoft.com/windows-vista/Import-or-export-certificates-and-private-keys).
|
||||
- You need a root certificate and a computer certificate on all devices that participate in the secure connection. Save the computer certificate in the **Personal/Certificates** folder.
|
||||
- For remote devices, you can create a secure website to facilitate access to the script and certificates.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Follow these procedures to verify and troubleshoot your IKEv2 IPsec connections:
|
||||
|
||||
**Use the Windows Firewall with Advanced Security snap-in to verify that a connection security rule is enabled.**
|
||||
|
||||
1. Open the Windows Firewall with Advanced Security console.
|
||||
|
||||
2. In the left pane of the Windows Firewall with Advanced Security snap-in, click **Connection Security Rules**, and then verify that there is an enabled connection security rule.
|
||||
|
||||
3. Expand **Monitoring**, and then click **Connection Security Rules** to verify that your IKEv2 rule is active for your currently active profile.
|
||||
|
||||
**Use Windows PowerShell cmdlets to display the security associations.**
|
||||
|
||||
1. Open a Windows PowerShell command prompt.
|
||||
|
||||
2. Type **get-NetIPsecQuickModeSA** to display the Quick Mode security associations.
|
||||
|
||||
3. Type **get-NetIPsecMainModeSA** to display the Main Mode security associations.
|
||||
|
||||
**Use netsh to capture IPsec events.**
|
||||
|
||||
1. Open an elevated command prompt.
|
||||
|
||||
2. At the command prompt, type **netsh wfp capture start**.
|
||||
|
||||
3. Reproduce the error event so that it can be captured.
|
||||
|
||||
4. At the command prompt, type **netsh wfp capture stop**.
|
||||
|
||||
A wfpdiag.cab file is created in the current folder.
|
||||
|
||||
5. Open the cab file, and then extract the wfpdiag.xml file.
|
||||
|
||||
6. Open the wfpdiag.xml file with your an XML viewer program or Notepad, and then examine the contents. There will be a lot of data in this file. One way to narrow down where to start looking is to search the last “errorFrequencyTable” at the end of the file. There might be many instances of this table, so make sure that you look at the last table in the file. For example, if you have a certificate problem, you might see the following entry in the last table at the end of the file:
|
||||
|
||||
``` syntax
|
||||
<item>
|
||||
<error>ERROR_IPSEC_IKE_NO_CERT</error>
|
||||
<frequency>32</frequency>
|
||||
</item>
|
||||
```
|
||||
In this example, there are 32 instances of the **ERROR\_IPSEC\_IKE\_NO\_CERT** error. So now you can search for **ERROR\_IPSEC\_IKE\_NO\_CERT** to get more details regarding this error.
|
||||
|
||||
You might not find the exact answer for the issue, but you can find good hints. For example, you might find that there seems to be an issue with the certificates, so you can look at your certificates and the related cmdlets for possible issues.
|
||||
|
||||
## See also
|
||||
|
||||
- [Windows Firewall with Advanced Security](windows-firewall-with-advanced-security.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,43 +2,48 @@
|
||||
title: Server Isolation Policy Design Example (Windows 10)
|
||||
description: Server Isolation Policy Design Example
|
||||
ms.assetid: 337e5f6b-1ec5-4b83-bee5-d0aea1fa5fc6
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Server Isolation Policy Design Example
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
This design example continues to use the fictitious company Woodgrove Bank, as described in the [Firewall Policy Design Example](firewall-policy-design-example.md) section and the [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md) section.
|
||||
|
||||
In addition to the protections provided by the firewall and domain isolation, Woodgrove Bank wants to provide additional protection to the computers that are running Microsoft SQL Server for the WGBank program. They contain personal data, including each customer's financial history. Government and industry rules and regulations specify that access to this information must be restricted to only those users who have a legitimate business need. This includes a requirement to prevent interception of and access to the information when it is in transit over the network.
|
||||
In addition to the protections provided by the firewall and domain isolation, Woodgrove Bank wants to provide additional protection to the devices that are running Microsoft SQL Server for the WGBank program. They contain personal data, including each customer's financial history. Government and industry rules and regulations specify that access to this information must be restricted to only those users who have a legitimate business need. This includes a requirement to prevent interception of and access to the information when it is in transit over the network.
|
||||
|
||||
The information presented by the WGBank front-end servers to the client computers, and the information presented by the WGPartner servers to the remote partner computers, are not considered sensitive for the purposes of the government regulations, because they are processed to remove sensitive elements before transmitting the data to the client computers.
|
||||
The information presented by the WGBank front-end servers to the client devices, and the information presented by the WGPartner servers to the remote partner devices, are not considered sensitive for the purposes of the government regulations, because they are processed to remove sensitive elements before transmitting the data to the client devices.
|
||||
|
||||
In this guide, the examples show server isolation layered on top of a domain isolation design. If you have an isolated domain, the client computers are already equipped with GPOs that require authentication. You only have to add settings to the isolated server(s) to require authentication on inbound connections, and to check for membership in the NAG. The connection attempt succeeds only if NAG membership is confirmed.
|
||||
In this guide, the examples show server isolation layered on top of a domain isolation design. If you have an isolated domain, the client devices are already equipped with GPOs that require authentication. You only have to add settings to the isolated server(s) to require authentication on inbound connections, and to check for membership in the NAG. The connection attempt succeeds only if NAG membership is confirmed.
|
||||
|
||||
## Server isolation without domain isolation
|
||||
|
||||
|
||||
Server isolation can also be deployed by itself, to only the computers that must participate. The GPO on the server is no different from the one discussed in the previous paragraph for a server in an existing isolated domain. The difference is that you must also deploy a GPO with supporting connection security rules to the clients that must be able to communicate with the isolated server. Because those computers must be members of the NAG, that group can also be used in a security group filter on the client GPO. That GPO must contain rules that support the authentication requirements of the isolated server.
|
||||
Server isolation can also be deployed by itself, to only the devices that must participate. The GPO on the server is no different from the one discussed in the previous paragraph for a server in an existing isolated domain. The difference is that you must also deploy a GPO with supporting connection security rules to the clients that must be able to communicate with the isolated server. Because those devices must be members of the NAG, that group can also be used in a security group filter on the client GPO. That GPO must contain rules that support the authentication requirements of the isolated server.
|
||||
|
||||
In short, instead of applying the client GPO to all clients in the domain, you apply the GPO to only the members of the NAG.
|
||||
|
||||
If you do not have an Active Directory domain then you can manually apply the connection security rules to the client computers, or you can use a netsh command-line script (or Windows PowerShell in Windows 8 and Windows Server 2012) to help automate the configuration of the rules on larger numbers of computers. If you do not have an Active Directory domain, you cannot use the Kerberos V5 protocol, but instead must provide the clients and the isolated servers with certificates that are referenced in the connection security rules.
|
||||
If you do not have an Active Directory domain, you can manually apply the connection security rules, use a netsh command-line script, or use a Windows PowerShell script to help automate the configuration of the rules on larger numbers of devices. If you do not have an Active Directory domain, you cannot use the Kerberos V5 protocol, but instead must provide the clients and the isolated servers with certificates that are referenced in the connection security rules.
|
||||
|
||||
## Design requirements
|
||||
|
||||
|
||||
In addition to the protection provided by the firewall rules and domain isolation described in the previous design examples, the network administrators want to implement server isolation to help protect the sensitive data stored on the computers that run SQL Server.
|
||||
In addition to the protection provided by the firewall rules and domain isolation described in the previous design examples, the network administrators want to implement server isolation to help protect the sensitive data stored on the devices that run SQL Server.
|
||||
|
||||
The following illustration shows the traffic protection needs for this design example.
|
||||
|
||||

|
||||
|
||||
1. Access to the SQL Server computers must be restricted to only those computer or user accounts that have a business requirement to access the data. This includes the service accounts that are used by the WGBank front-end servers, and administrators of the SQL Server computers. In addition, access is only granted when it is sent from an authorized computer. Authorization is determined by membership in a network access group (NAG).
|
||||
1. Access to the SQL Server devices must be restricted to only those computer or user accounts that have a business requirement to access the data. This includes the service accounts that are used by the WGBank front-end servers, and administrators of the SQL Server devices. In addition, access is only granted when it is sent from an authorized computer. Authorization is determined by membership in a network access group (NAG).
|
||||
|
||||
2. All network traffic to and from the SQL Server computers must be encrypted.
|
||||
2. All network traffic to and from the SQL Server devices must be encrypted.
|
||||
|
||||
3. Client computers or users whose accounts are not members of the NAG cannot access the isolated servers.
|
||||
3. Client devices or users whose accounts are not members of the NAG cannot access the isolated servers.
|
||||
|
||||
**Other traffic notes:**
|
||||
|
||||
@ -48,40 +53,25 @@ The following illustration shows the traffic protection needs for this design ex
|
||||
|
||||
## Design details
|
||||
|
||||
Woodgrove Bank uses Active Directory groups and GPOs to deploy the server isolation settings and rules to the devices on its network.
|
||||
|
||||
Woodgrove Bank uses Active Directory groups and GPOs to deploy the server isolation settings and rules to the computers on its network.
|
||||
As in the previously described policy design examples, GPOs to implement the domain isolation environment are linked to the domain container in Active Directory, and then WMI filters and security group filters are attached to GPOs to ensure that the correct GPO is applied to each computer. The following groups were created by using the Active Directory Users and Computers snap-in, and all devices that run Windows were added to the correct groups.
|
||||
|
||||
As in the previously described policy design examples, GPOs to implement the domain isolation environment are linked to the domain container in Active Directory, and then WMI filters and security group filters are attached to GPOs to ensure that the correct GPO is applied to each computer. The following groups were created by using the Active Directory Users and Computers snap-in, and all computers that run Windows were added to the correct groups.
|
||||
- **CG\_SRVISO\_WGBANK\_SQL**. This group contains the computer accounts for the devices that run SQL Server. Members of this group receive a GPO with firewall and connections security rules that require that only users who are members of the group CG\_NAG\_SQL\_USERS can access the server, and only when they are using a computer that is a member of the group CG\_NAG\_SQL\_COMPUTERS.
|
||||
|
||||
- **CG\_SRVISO\_WGBANK\_SQL**. This group contains the computer accounts for the computers that run SQL Server. Members of this group receive a GPO with firewall and connections security rules that require that only users who are members of the group CG\_NAG\_SQL\_USERS can access the server, and only when they are using a computer that is a member of the group CG\_NAG\_SQL\_COMPUTERS.
|
||||
|
||||
**Note**
|
||||
If you are designing GPOs for only Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2, you can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, computers that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any computers that are incorrectly assigned to more than one group.
|
||||
>**Note:** You can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, devices that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any devices that are incorrectly assigned to more than one group.
|
||||
|
||||
|
||||
Network access groups (NAGs) are not used to determine which GPOs are applied to a computer. Instead, these groups determine which users and devices can access the services on the isolated server.
|
||||
|
||||
Network access groups (NAGs) are not used to determine which GPOs are applied to a computer. Instead, these groups determine which users and computers can access the services on the isolated server.
|
||||
- **CG\_NAG\_SQL\_COMPUTERS**. This network access group contains the computer accounts that are able to access the devices running SQL Server hosting the WGBank data. Members of this group include the WGBank front-end servers, and some client devices from which SQL Server administrators are permitted to work on the servers.
|
||||
|
||||
- **CG\_NAG\_SQL\_COMPUTERS**. This network access group contains the computer accounts that are able to access the computers running SQL Server hosting the WGBank data. Members of this group include the WGBank front-end servers, and some client computers from which SQL Server administrators are permitted to work on the servers.
|
||||
- **CG\_NAG\_SQL\_USERS**. This network access group contains the user accounts of users who are permitted to access the SQL Server devices that host the WGBank data. Members of this group include the service account that the WGBank front-end program uses to run on its devices, and the user accounts for the SQL Server administration team members.
|
||||
|
||||
- **CG\_NAG\_SQL\_USERS**. This network access group contains the user accounts of users who are permitted to access the SQL Server computers that host the WGBank data. Members of this group include the service account that the WGBank front-end program uses to run on its computers, and the user accounts for the SQL Server administration team members.
|
||||
>**Note:** You can use a single group for both user and computer accounts. Woodgrove Bank chose to keep them separate for clarity.
|
||||
|
||||
**Note**
|
||||
You can use a single group for both user and computer accounts. Woodgrove Bank chose to keep them separate for clarity.
|
||||
If Woodgrove Bank wants to implement server isolation without domain isolation, the CG\_NAG\_SQL\_COMPUTERS group can also be attached as a security group filter on the GPOs that apply connection security rules to the client devices. By doing this, all the devices that are authorized to access the isolated server also have the required connection security rules.
|
||||
|
||||
|
||||
|
||||
If Woodgrove Bank wants to implement server isolation without domain isolation, the CG\_NAG\_SQL\_COMPUTERS group can also be attached as a security group filter on the GPOs that apply connection security rules to the client computers. By doing this, all the computers that are authorized to access the isolated server also have the required connection security rules.
|
||||
|
||||
You do not have to include the encryption-capable rules on all computers. Instead, you can create GPOs that are applied only to members of the NAG, in addition to the standard domain isolation GPO, that contain connection security rules to support encryption.
|
||||
You do not have to include the encryption-capable rules on all devices. Instead, you can create GPOs that are applied only to members of the NAG, in addition to the standard domain isolation GPO, that contain connection security rules to support encryption.
|
||||
|
||||
**Next: **[Certificate-based Isolation Policy Design Example](certificate-based-isolation-policy-design-example.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -2,17 +2,24 @@
|
||||
title: Server Isolation Policy Design (Windows 10)
|
||||
description: Server Isolation Policy Design
|
||||
ms.assetid: f93f65cd-b863-461e-ab5d-a620fd962c9a
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Server Isolation Policy Design
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
In the server isolation policy design, you assign servers to a zone that allows access only to users and computers that authenticate as members of an approved network access group (NAG).
|
||||
In the server isolation policy design, you assign servers to a zone that allows access only to users and devices that authenticate as members of an approved network access group (NAG).
|
||||
|
||||
This design typically begins with a network configured as described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) section. For this design, you then create zones for servers that have additional security requirements. The zones can limit access to the server to only members of authorized groups, and can optionally require the encryption of all traffic in or out of these servers. This can be done on a per server basis, or for a group of servers that share common security requirements.
|
||||
|
||||
You can implement a server isolation design without using domain isolation. To do this, you use the same principles as domain isolation, but instead of applying them to an Active Directory domain, you apply them only to the computers that must be able to access the isolated servers. The GPO contains connection security and firewall rules that require authentication when communicating with the isolated servers. In this case, the NAGs that determine which users and computers can access the isolated server are also used to determine which computers receive the GPO.
|
||||
You can implement a server isolation design without using domain isolation. To do this, you use the same principles as domain isolation, but instead of applying them to an Active Directory domain, you apply them only to the devices that must be able to access the isolated servers. The GPO contains connection security and firewall rules that require authentication when communicating with the isolated servers. In this case, the NAGs that determine which users and devices can access the isolated server are also used to determine which devices receive the GPO.
|
||||
|
||||
The design is shown in the following illustration, with arrows that show the permitted communication paths.
|
||||
|
||||
@ -20,24 +27,21 @@ The design is shown in the following illustration, with arrows that show the per
|
||||
|
||||
Characteristics of this design include the following:
|
||||
|
||||
- Isolated domain (area A) - The same isolated domain described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) section. If the isolated domain includes a boundary zone, then computers in the boundary zone behave just like other members of the isolated domain in the way that they interact with computers in server isolation zones.
|
||||
- Isolated domain (area A) - The same isolated domain described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) section. If the isolated domain includes a boundary zone, then devices in the boundary zone behave just like other members of the isolated domain in the way that they interact with devices in server isolation zones.
|
||||
|
||||
- Isolated servers (area B) - Computers in the server isolation zones restrict access to computers, and optionally users, that authenticate as a member of a network access group (NAG) authorized to gain access.
|
||||
- Isolated servers (area B) - Devices in the server isolation zones restrict access to devices, and optionally users, that authenticate as a member of a network access group (NAG) authorized to gain access.
|
||||
|
||||
- Encryption zone (area C) - If the data being exchanged is sufficiently sensitive, the connection security rules for the zone can also require that the network traffic be encrypted. Encryption zones are most often implemented as rules that are part of a server isolation zone, instead of as a separate zone. The diagram illustrates the concept as a subset for conceptual purposes only.
|
||||
|
||||
To add support for server isolation, you must ensure that the authentication methods are compatible with the requirements of the isolated server. For example, if you want to authorize user accounts that are members of a NAG in addition to authorizing computer accounts, you must enable both user and computer authentication in your connection security rules.
|
||||
|
||||
**Important**
|
||||
This design builds on the [Domain Isolation Policy Design](domain-isolation-policy-design.md), which in turn builds on the [Basic Firewall Policy Design](basic-firewall-policy-design.md). If you plan to deploy all three designs, do the design work for all three together, and then deploy in the sequence presented.
|
||||
>**Important:** This design builds on the [Domain Isolation Policy Design](domain-isolation-policy-design.md), which in turn builds on the [Basic Firewall Policy Design](basic-firewall-policy-design.md). If you plan to deploy all three designs, do the design work for all three together, and then deploy in the sequence presented.
|
||||
|
||||
|
||||
This design can be applied to devices that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the connection security rules.
|
||||
|
||||
This design can be applied to computers that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the connection security rules.
|
||||
For more info about this design:
|
||||
|
||||
For more information about this design:
|
||||
|
||||
- This design coincides with the deployment goals to [Protect Computers from Unwanted Network Traffic](protect-computers-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Computers](restrict-access-to-only-trusted-computers.md), [Restrict Access to Only Specified Users or Computers](restrict-access-to-only-specified-users-or-computers.md), and [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
|
||||
- This design coincides with the deployment goals to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md), [Restrict Access to Only Specified Users or Devices](restrict-access-to-only-specified-users-or-devices.md), and [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
|
||||
|
||||
- To learn more about this design, see [Server Isolation Policy Design Example](server-isolation-policy-design-example.md).
|
||||
|
||||
@ -45,15 +49,6 @@ For more information about this design:
|
||||
|
||||
- To help you make the decisions required in this design, see [Planning Server Isolation Zones](planning-server-isolation-zones.md) and [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md).
|
||||
|
||||
- For a list of tasks that you can use to deploy your server isolation policy design, see "Checklist: Implementing a Standalone Server Isolation Policy Design" in the [Windows Firewall with Advanced Security Deployment Guide](http://go.microsoft.com/fwlink/?linkid=xxxxx) at http://go.microsoft.com/fwlink/?linkid=xxxx.
|
||||
- For a list of tasks that you can use to deploy your server isolation policy design, see [Checklist: Implementing a Standalone Server Isolation Policy Design](checklist-implementing-a-standalone-server-isolation-policy-design.md).
|
||||
|
||||
**Next: **[Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
Reference in New Issue
Block a user