Server and Domain Isolation Using IPsec and Group Policy

The objective of this chapter is to provide instructions for implementation of the server and domain isolation design. The previous chapters explain the design process and rationale behind the guidance that this chapter provides. If you have not already done so, it is strongly recommended that you read these chapters before continuing with this one.

This chapter provides complete guidance for implementing the security requirements of domain isolation and the server isolation groups designed in Chapter 4, "Designing and Planning Isolation Groups." A combination of the following elements will implement these requirements:

This guidance discusses the preparation of the solution using Group Policy and IPsec policies in the Active Directory® directory service using Microsoft® Windows Server™ 2003, and configuration of domain members using Windows Server 2003 and Microsoft Windows® XP. Additionally, this chapter discusses design alternatives and rollout options. Final check lists are provided to ensure that the design meets all of the business and security requirements.

On This Page

	Chapter Prerequisites
	Summary

Chapter Prerequisites

This section contains information that will help you determine your organization's readiness to implement the IPsec solution. (Readiness is meant in a logistical sense rather than a business sense—the business motivation for implementing this solution is discussed in Chapter 1, "Introduction to Server and Domain Isolation," of this guide.)

Knowledge Prerequisites

You should be familiar with general concepts of IPsec and the Microsoft implementation of IPsec in particular. Familiarity with Windows Server 2003 is also required in the following areas:

Before proceeding with this chapter, you should also have read the planning guidance that the earlier chapters in this guide provide and have a thorough understanding of the architecture and design of the solution. You also should have defined and documented the business requirements of the solution as part of the solution requirements matrix.

Organizational Prerequisites

You should consult with other people in your organization who may need to be involved in the implementation of this solution, including the following:

Note   Depending on the structure of your information technology (IT) organization, these roles may be filled by a number of people, or there may be fewer people spanning several roles.

IT Infrastructure Prerequisites

This chapter also assumes that the following IT infrastructure exists:

This chapter also requires a complete understanding of the existing IT infrastructure to ensure that the correct policies are deployed to the intended hosts in the environment. Chapter 3, "Determining the Current State of Your IT Infrastructure," describes the required information and how to obtain.

You should not undertake the steps that this chapter describes until you have obtained at least the following information:

Creating IPsec Policies in Active Directory

The process of creating the necessary policies to support the required isolation groups consists of the following main tasks:

Before undertaking the process of creating these components, it is important to obtain the traffic model diagrams and tables from Chapter 4, "Designing and Planning Isolation Groups," and the host and network mapping tables. These tables provide the necessary information to ensure that the policies provide the required functionality and are assigned to the correct isolation groups.

The following figure depicts the network configuration that was used to simulate the Woodgrove Bank scenario.

Figure 5.1  Woodgrove Bank network configuration
See full-sized image

The Woodgrove Bank test lab configuration demonstrates the following key capabilities of the solution:

In addition, this lab environment demonstrates the following required functionalities of Windows IPsec and test compatibility with other security technologies that would be used in real-world environments:

The lab scenario illustrated in figure 5.1 was used to test that the correct functionality was achieved in all of the isolation groups for the solution. In total, four IPsec policies were created and assigned to the isolation groups shown in bold dashes in the figure (that is, the Isolation domain, the Encryption isolation group, the No Fallback isolation group, and the Boundary isolation group.) The following sections explain how these policies were created.

IPsec Policy Component Overview

An IPsec policy consists of a number of components that are used to enforce the IPsec security requirements of the organization. The following figure depicts the various components of an IPsec policy and how they are associated with each other.

Figure 5.2  IPsec policy components
See full-sized image

The IPsec policy acts as a container for a set of rules that determine what and how network communications traffic will be allowed. Each of the rules consists of a filter list and an associated action. The filter list contains a grouping of filters. As traffic is matched to a specific filter, the associated filter action is triggered. In addition, the rules define which authentication methods are used between hosts.

This diagram depicts the policy components from the top down. However, the most effective way to build policies is to start with the filters and filter lists, because they are the fundamental building blocks that control which traffic is secured.

IPsec Filter Lists

IPsec filter lists are collections of one or more filters that are used to match network traffic based on the criteria for each filter. Each filter in the filter list defines the following:

Filter lists and filter actions were designed to be shared among IPsec policies. This approach allows one filter list to be maintained for a certain type of exemption and used in the individual IPsec policy for each isolation group. However, filters that make up the filter lists cannot be shared between filter lists. If two filter lists have identical filters, the filters will have to be created twice, once for each filter list.

The IPsec administrator should carefully avoid duplicate filters in an IPsec policy because the filters may have separate actions. The IPsec service may change the ordering of duplicate filters to packet processing and yield inconsistent results. Duplicate filters may be used if necessary when the filters have exactly the same action, such as permit or block, and performance is not affected.

The network information gathered earlier is used to identify the various traffic patterns that the administrator wants to secure. In addition, the information is used to identify any traffic that might need to be exempted from the IPsec restrictions.

The following table describes some basic filter lists that might exist in a typical organization. Depending on the organization's business requirements and network design, additional filter lists may be required.

Table 5.1  Solution-Provided Filter Lists

The Secure Subnets List contains all of the subnets within the organization's internal network. This filter list is associated with a filter action that implements the actions required for a particular isolation group. This action is the broadest security action for all network traffic for that subnet (for example, negotiate IPsec), because other filters, like the one for ICMP, will be more specific to require a different action (such as permit). It is important to remember that this approach means that no untrusted or non-IPsec hosts should be on those subnets.

The filters must implement both inbound and outbound security requirements. When defining the filters, they should be configured as mirrored. Mirroring ensures that traffic is matched when the exact opposite source and destination addresses are used. When describing filters, the symbol "<->" is used to signify that the filter is mirrored. Mirrored filters must be used whenever the filter action negotiates security methods for IPsec encapsulation.

Source and Destination Addresses

Each filter has a setting for both the source and destination addresses. Windows XP and Windows Server 2003 have more options for addresses than Windows 2000. So you should use only Windows 2000 settings when this platform is a member of the domain. The Windows 2000 settings are explained as follows:

Note   Windows XP and Windows Server 2003 were enhanced to provide additional address options, as well as a number of other options supported by those releases. If the same IPsec policy will be applied to multiple platforms, the administrator must ensure that only Windows 2000 options are used in the policy design.

Protocols

In addition to source and destination address configuration, each filter can be configured to match against a specific protocol or port. By default the filter will match traffic on all protocols and all ports. If a specific protocol that supports ports is selected as part of the filter criteria, the administrator has the option to also configure source and destination ports.

Source and Destination Ports

Although filters can be configured to match against the TCP or UDP ports, this solution does not recommend creating port-specific filters. Port filtering greatly increases the administrative overhead and complexity of the configuration of the IPsec filters and can require complex coordination between client and server policies for IKE to successfully negotiate security. Because this solution assumes that communication between trusted computers is in fact trusted, the filters allow all traffic (except ICMP) to be secured by IPsec. If port filtering on the trusted host is required, see Business_Requirements.xls for security requirements that are met by using the combination of IPsec and a host-based firewall (such as Windows Firewall) positioned above the IPsec layer.

To work around a number of the issues mentioned in Appendix A regarding the behavior of filters using "My IP Address," this solution uses Any <-> subnet filters for the Woodgrove Bank scenario. A filter list is created that consists of multiple Any IP Address <-> A Specific Subnet filters in which all the organization's subnets are listed explicitly. This approach allows the administrator to define the specific subnets that should be secured. Any traffic outside the specified subnets will not match any IPsec filters and will be sent through in plaintext to the destination host.

For additional best practice recommendations in filter design, see the "Best Practices" section of the IT Showcase white paper, "Improving Security with Domain Isolation”.

Exemption List Considerations

Some traffic cannot be protected by IPsec for support, technical, or business reasons. Also, computers that are not running the Windows operating system might not support IPsec or have IPsec easily deployed to them. Computers running older versions of Windows such as Microsoft Windows NT® version 4.0, Windows 95, and Windows 98 are unable to process Group Policy-based IPsec. Finally, unmanaged computers that run Windows 2000 or later can only participate in the IPsec negotiation if the policy is manually rolled out to the individual computers and some form of authentication other than the Kerberos version 5 protocol (such as a preshared key or certificate) is used.

In addition, a computer running Windows 2000 or later needs to have network connectivity and be able to obtain an IPsec policy from the domain before it can establish IPsec. Currently, connecting to the network, locating a domain controller, and retrieving the policy requires that the supporting infrastructure services be exempted from IPsec security. These services include naming services such as DNS and WINS and the domain controllers themselves.

In addition to these infrastructure services, other services that do not support IPsec might exist in the organization. For example, thin clients or other bootstrap clients that need to download an image from Advanced Deployment Services (ADS) or Remote Installation Services (RIS) do not support IPsec. If servers that provide these services exist on your network, you should examine them for inclusion in an exemption list or make them members of the Boundary isolation group so that they can accept network communications from hosts that are unable to use IPsec.

Note   Deciding whether to include servers that provide ADS, RIS, or other such services on exemption lists or make them members of the Boundary isolation group is based on factors of risk and manageability. In either case, you should thoroughly test the approach that you have chosen.

If a client is not able to participate in the IPsec infrastructure but has a business need to access a server that is using IPsec, you must implement some method to allow a communication path to be established. The solution in this guide uses exemption filter lists to control these traffic requirements through permits. Exemption lists are designed into the IPsec infrastructure to ensure that all required host communications can occur, even if IPsec negotiations cannot be used.

Exemption lists are used to selectively opt out traffic from participating in the IPsec infrastructure by permitting traffic that matches the exemption lists' filters. These lists need to be carefully designed, because they bypass the security mechanisms that IPsec implements. For example, placing a server that is typically secured through the use of encryption (to protect proprietary information) in an exemption filter will allow guest computers to communicate directly with the server without using IPsec.

The exemption lists are implemented as filter lists to help minimize the list size for easier user interface (UI) configuration. For example, you should have a filter list that contains the filters for all domain controllers, or for domain controllers in each domain. A second advantage in having several filter lists is that the permit rule can be disabled/enabled in IPsec policy easily for each filter list.

When designing a rule to implement the exemption in IPsec policy, you want to permit the least amount of traffic necessary to be unprotected by IPsec. However, there are tradeoffs in terms of the complexity and size of the IPsec policy as opposed to the security gained by using the most specific filters. Note that all domain controller IP addresses in all trusted forests must be exempted in order for clients in one domain or forest to be able to obtain Kerberos tickets for servers in another trusted domain or forest. The Windows Kerberos client requires ICMP, Lightweight Directory Access Protocol (LDAP) UDP 389, and Kerberos UDP 88 and TCP 88 traffic to both its own domain controllers and to domain controllers in other domains. Domain members require additional types of traffic with the domain controllers of their own domain such as server message block (SMB) TCP 445, remote procedure call (RPC), and LDAP TCP 389. Where security requirements are not extreme, the exemption is implemented for "all traffic" with the domain controller IP addresses for simplicity and to reduce the number of filters.

It is tempting to want to exempt particular application traffic by port instead of by destination address to avoid having to maintain a list of addresses, such as outbound Telnet using TCP port 23 to access UNIX systems. For example, consider the following outbound exemption:

    My IP Address to Any IP address, TCP, src port Any, dst port 23, mirrored

The corresponding inbound filter would be as follows:

    Any IP Address to My IP address, TCP, src port 23, dst port Any

This inbound filter would allow responses from Telnet connection requests, but it would also allow an attacker to bypass IPsec authentication requirements and access any open port on the host. Organizations will have to carefully evaluate the security risk of such a potential attack before using this filter design. The risk is certainly minimized if the destination IP address is specified. This same situation can exist if default exemption for the Kerberos authentication protocol is not disabled. See Microsoft Knowledge Base articles 811832 “IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios” and 810207 “IPSec default exemptions are removed in Windows Server 2003” for detailed discussion of the design and security impact of default exemptions. You should design IPsec policies with the assumption that no default exemptions are enabled.

Placing system addresses in an exemption list effectively exempts those systems from participating as IPsec hosts for all IPsec policies that implement the exemption list. Because most clients in the organization (including guest clients) will typically need access to infrastructure services such as DHCP, DNS, or WINS, the servers that provide these services are usually implemented in this manner.

Woodgrove Bank Filter Lists

After analyzing the traffic requirements output from Chapter 4, Woodgrove Bank administrators mapped out the filter lists in the following table:

Table 5.2  Woodgrove Bank Filter List Examples

The Woodgrove Bank designers followed the guidance provided in this chapter to create these filter lists. The first list—the Secure Subnets list—consists of two filters:

These subnet filters are mirrored to match both inbound and outbound traffic and are configured to trigger on any protocol. This filter list, when paired with the appropriate filter action, will implement the isolation groups.

The Woodgrove Bank designers then chose to implement an exemption list for ICMP network traffic. This filter list is comprised of a single mirrored filter (My IP Address <-> Any) that is configured for ICMP network traffic only. This approach allows administrators to use the Ping utility as a troubleshooting tool in the environment, regardless of whether an IPsec security association (SA) has been negotiated. This approach was also necessary because path maximum transmission unit (MTU) discovery is required for this solution to work correctly. For DHCP traffic, the Woodgrove Bank designers created a new filter for UDP port 68 to allow DHCP clients to receive traffic from the DHCP server.

In addition, Woodgrove Bank had some line of business (LOB) applications that were running on servers that are unable to participate in the IPsec infrastructure. To accommodate those services, they created a new exemption filter list called LOB Application Servers Exemption List and added an Any <-> 192.168.1.10 filter for the system hosting the LOB application.

Finally, the Woodgrove Bank design team identified its infrastructure services and created the corresponding exemption filter lists to allow all clients to communicate directly to the servers that provide these services, regardless of the IPsec settings for the isolation groups. Specific exemption lists were created for the following services:

These filter lists are comprised of mirrored filters that define Any <-> Specific IP Address, and these filters are configured to trigger on any protocol. The number of computers in the exemption filter lists should be kept to a minimum because all traffic is exempted to these computers, and all computers in the exemption list have full TCP/IP access to all trusted hosts in the Isolation domain. Accordingly, this approach could present a larger attack surface than what otherwise might be present. See the Business_Requirements.xls spreadsheet (in the Tools and Templates folder) for details of requirements to mitigate the risk of inbound traffic from IP addresses that are exempted.

Woodgrove Bank chose to manage two separate lists for DNS servers and domain controllers, even though the IP addresses are the same. Woodgrove took this approach because both filter lists will have the exact same action, permit. Also, the Woodgrove production network uses DNS servers in some areas that are not also domain controllers.

Instead of having specific destination IP addresses, the filter for DHCP was designed to match all DHCP client outbound traffic. The mirror of this filter will permit responses from DHCP servers. As discussed, it may also permit inbound attacks from any IP address using source port 67. However, the inbound attack is limited to destination port 68 on the client, which the DHCP client is using. Woodgrove Bank used this design to avoid having filters for every DHCP server, and because its risk assessment did not rank highly the risks of inbound attacks to the DHCP client port or the risk of unauthorized DHCP servers.

This section does not include the full description for each filter. However, it is recommended that you use the filter description field to carefully define each filter, because the IPsec monitor and command-line tools display each filter's description, not the information in the filter list.

IPsec Filter Actions

The filter actions define how IP packets are handled after they are matched to a filter within a filter list. Filter actions are the basis for implementing the various isolation groups. Although there are three default filter actions provided with the Windows operating system, it is recommended that you remove these and create new filter actions this approach allows you to ensure that only the actions that you create as part of your design are being used. Each filter action is comprised of a name, description, and security method.

Name

Give the filter action a meaningful name that reflects what the filter action does.

Description

Type a detailed description of the filter action behavior in the description field.

Security Methods

The security methods that are implemented within the filter action are determined by the requirements for processing packets that match the associated filters in the filter list. The following three options are available:

The following table lists the possible cryptographic options for each security method:

Table 5.3  Security and Cryptographic Options

The Windows 2000 SP4, Windows XP SP2, and Windows Server 2003 IPsec implementations now support NAT-T techniques for IPsec transport mode ESP, in addition to supporting NAT-T for L2TP/IPsec VPN client tunnels. The NAT-T update is required for Windows 2000 SP4. The Windows 2000 and Windows XP support for IPsec transport mode NAT-T is limited for Windows 2000 and Windows XP versions prior to SP2 because TCP Path MTU (PMTU) detection is not supported for IPsec-protected TCP traffic. Windows Server 2003 does have this support. NAT-T techniques use a UDP header after the IP header to encapsulate ESP. IKE automatically detects when NAT exists in the path and uses UDP-ESP whenever ESP is allowed in the security method list. Also, it is worth noting that current Windows IPsec implementations do not support the U.S. Federal government Advanced Encryption Standard (AES). This will change in future versions of Windows.

The following cryptographic options are available for AH and ESP:

ESP can be configured to use no encryption algorithm, in which case only data integrity and authenticity is enforced. This configuration is commonly called ESP-Null, and it provides the ability to authenticate the hosts prior to establishing a communication connection and performing an integrity check on the data part of the IP packet carried within the ESP packet.

ESP can also encrypt the data section of the IP packet. The following two cryptographic options are available:

You can combine AH and ESP protocols with one another if required to meet very high security requirements. For example, if there is a clear requirement for IP header integrity in addition to data encryption, you can configure the security method to use AH with SHA-1 integrity and ESP – 3DES Encryption. If only data integrity is required, then you can use ESP-null with SHA-1.

Although you can select any combination of the security options, it is important to recognize that AH provides both data and address header integrity. Using AH and ESP to provide integrity does not provide any additional integrity protection for packet data; it just increases the workload associated with processing the packet. In addition, ESP combined with AH will not overcome the NAT barrier issues that AH faces. Therefore, using AH in addition to ESP is appropriate for only the highest security environments.

Careful planning is required when designing the security methods of the filter actions. For two computers to successfully negotiate, they need to have at least one security method in common in their respective filter actions. Each filter action may contain more than one negotiation method to accommodate different types of negotiation. For example, a system may typically only negotiate ESP-Null, but the filter action may also contain a negotiation method for ESP-3DES. This approach will allow the system to negotiate a 3DES encryption connection if required.

In addition to selecting the security methods, you can set the session key settings for each security method if required. In its default setting, the IPsec SA lifetimes are configured to be when 100 megabytes (MB) of data are passed or after one hour has elapsed. These settings control when a new pair of IPsec security associations is renegotiated by IKE quick mode. The IKE quick mode process is called "rekeying" but does not actually just refresh keys for an existing IPsec SA pair. IPsec must discard packets if the lifetime expires; therefore, it attempts to renegotiate well before either the lifetime for bytes or seconds expires. If the lifetime is set too low, then packets can be lost. Similarly, CPU usage may be increased for servers maintaining IPsec SAs with many clients. Renewing IPsec SAs ensures that an attacker is unable to decipher the entire communication even if they manage to determine one of the session keys. As the lifetime increases, more information is available to the attacker about the session key. Therefore, you should not change the lifetimes unless operational needs require it, and you can write specific security requirements that define an appropriate level of protection against sophisticated cryptographic attacks.

Security Negotiation Options

You can set the following security negotiation options for IPsec policies:

Inbound Passthrough

The Inbound passthrough option was designed to be used in an internal server policy so that client policy could use the non-intrusive "default response" rule. With this option enabled, a plaintext connection request that matches an inbound filter will be accepted. The server's connection reply matches the outbound filter to trigger an IKE main mode negotiation request to the client.

You should not enable this option should on Internet-facing computers, because it allows inbound attacks to pass through the IPsec layer. It also forces the server to attempt an IPsec SA negotiation to the source IP of any incoming packet. By spoofing source IP addresses, the attacker can cause denial of service on the server as IKE tries to negotiate with hundreds or thousands of invalid IP addresses.

To enable Inbound passthrough, select Accept unsecured communication, but always respond using IPsec in the Manage Filter Actions dialog box.

Note   If the policies assigned to the clients do not enable the default response rule, you should disable this option, because there will be no response for IPsec communication. In addition, it can be used as a denial of service attack vector.

Fall Back to Clear

The Fall back to clear option controls the ability for the (source) computer to allow traffic to be sent without IPsec protection if the initial IKE main mode negotiation does not get a response from a target destination computer. Hosts that do not support IPsec will not be able to reply (using IKE) to the IKE negotiation request. These hosts are referred to as being "non-IPsec-aware" computers. However, the lack of an IKE main mode response does not necessarily mean that the computer is not capable of IPsec; it might be an IPsec-capable computer that does not have an active IPsec policy. Or the active IPsec policy might only have permit and block actions. Or the active IPsec policy may not be designed to negotiate with the source computer's IP address. In IPsec terminology, network traffic that does not use IPsec is referred to as in plaintext. If there is no response from the target computer in three seconds, a soft security association (soft SA) will be created, and communication will begin in plaintext. For initial deployments, it is recommended that this option be enabled so that clients can communicate with hosts that do not have IPsec enabled. Also, using this option also helps re-establish plaintext connectivity temporarily when the IPsec service is stopped for troubleshooting. If the target computer does provide an IKE response and there is a failure during the IKE negotiation for any reason, IPsec on the source computer will discard the outbound packets, effectively blocking the communication.

To enable the Fall back to clear option, select Allow unsecured communication with non-IPsec-aware computers in the Manage Filter Actions dialog box.

Note   The way this option functions has changed on computers that run Windows 2000 SP3 or later, Windows XP SP1, or Windows Server 2003. If only this option is enabled, the system will be able to initiate communication in the clear but will not accept any communication requests from non-IPsec aware systems. If the system needs to respond to requests from and initiate communication to non-IPsec aware systems, you must select both the Accept unsecured communication, but always respond using IPsec option and the Allow unsecured communication with non-IPsec-aware computers option.

If the system is running Windows 2000 or Windows XP without the appropriate service packs, the client will accept unsecured communication requests when Allow unsecured communication with non-IPsec-aware computers is selected, even when Accept unsecured communication, but always respond using IPsec is not selected. This behavior occurs because when the Allow unsecured communication with non-IPsec-aware computers option is selected, IPsec processes the associated inbound filter as an Inbound passthrough filter (the same behavior that occurs when Accept unsecured communication, but always respond using IPsec is selected).

Use Session Key Perfect Forward Secrecy

The Use session key perfect forward secrecy (PFS) option determines whether the master key material can be used to generate all the session keys or just the first session key. If this option is enabled, the master key can only be used once, and each additional session key renegotiation will require a new key exchange to be performed to generate a new master key before generating the session key. This requirement ensures that if the master key is compromised, the attacker cannot generate additional session keys to decrypt the traffic stream. Enabling this option is not recommended because of the additional overhead cost of performing a key exchange at each session key renewal interval.

For more information about the Inbound passthrough, Fall back to clear, and Session key and Master key PFS options, see the "Security Negotiation Options" section in Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server.

Woodgrove Bank IPsec Filter Actions

The following table provides the filter action names and descriptions that are used to implement the various isolation groups for the Woodgrove Bank scenario:

Table 5.4  IPsec Filter Actions and Descriptions

The first two filter actions are straightforward. The block filter action will drop any traffic that matches a filter in a filter list associated with this action. The permit filter action will allow the traffic to occur for any associated filter list that has the matching filter. The final four filter actions in Table 5.4 are used to implement the isolation groups in the Woodgrove Bank scenario.

Woodgrove Bank administrators have four security isolation groups to implement. To deploy this configuration, you must define a minimum of three filter actions with custom security negotiation methods in addition to the permit and block filter actions.

Woodgrove Bank has no additional requirements for isolating computers from each other within a specific security isolation group. The bank has determined that the four negotiated filter actions in the following table are sufficient to implement its environment:

Table 5.5  Supported Security Methods

Woodgrove uses IPsec ESP instead of AH because of the presence of network devices in the organization that use NAT.

Woodgrove Bank also had a requirement to implement encryption for some of the servers in the organization. Therefore, all policies needed the option to use encryption. For these reasons, Woodgrove Bank chose to implement its security based solely on IPsec ESP.

For ESP integrity, Woodgrove Bank chose to use SHA-1 instead of MD5 for its stronger security, but also because it is required to meet U.S. government regulations on processing financial information that included using approved algorithms.

Woodgrove Bank chose not to implement PFS on any of the filter actions because it did not have a specific security threat that required the use of PFS. Woodgrove also made this decision to avoid the performance impact on the computers caused by the key renegotiation.

Isolation Domain Filter Action

To implement the Isolation domain, the Woodgrove Bank administrators created the IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) filter action.

Woodgrove Bank has several business requirements for communication between hosts in the Isolation domain and other isolation groups. Accordingly, clients in the Isolation domain perform the following actions described in the tables 4.5 and 4.6 of Chapter 4 of this guide:

Clients in the Isolation domain cannot accept communications from untrusted systems.

Remember that IPsec policy uses filters and filter actions to intercept and control inbound and outbound IP packets. Although IKE does authenticate both computers, the group membership of a computer using a certain IP address is not known at the time the initial connection request is sent outbound. Therefore, IPsec and IKE cannot be configured specifically to initiate communications in a certain way with a particular identity or isolation group. Also, computers that are members of these isolation groups may be located anywhere on the internal network. Therefore, you cannot use IP addresses to define or approximate isolation groups.

In order to implement these requirements in an IPsec policy, you must design the filter action to work with the filter list that specifies all internal subnets. You can reduce the preceding requirements into two basic behaviors:

To enable communications with the Encryption isolation group, the security methods include the security methods (ESP–SHA-1–3DES algorithms) that are defined for the Encryption isolation group. For more information about the encryption security negotiation methods, see the "Encryption Isolation Group Filter Action" section later in this chapter.

For traffic within the Isolation domain, and with the Boundary and No Fallback isolation groups, Woodgrove Bank uses ESP-null with SHA-1.

You must disable the Accept unsecured communication, but always respond with IPsec option on the filter action so that inbound plaintext will be ignored. This approach ensures that hosts in the Isolation domain will not accept traffic from any computer that is not participating in the IPsec environment.

The IPSEC – Secure Request Security (Ignore Inbound, Allow Outbound) filter action is configured to allow the members of the Isolation domain to initiate communications with untrusted systems. This behavior is implemented by enabling the Allow unsecured communication with non-IPsec-aware computers option on the filter action. If a trusted host in the Isolation domain initiates an outbound connection to an untrusted host (or another non-IPsec-aware system), the IPsec soft SA is established and remains active for five minutes after traffic stops flowing. Therefore, that untrusted system is able to initiate new plaintext connections back into the trusted host during this time. After the soft SA times out, the trusted host will no longer accept plaintext traffic from that system. IPsec filtering and soft SA support was not designed to provide connection-specific protections, such as stateful filtering, like many firewalls do. Soft SAs allow all traffic that matches the associated filter. For more information about this process, see the "IKE Main Mode SAs and IPsec SAs" section of Appendix A, "Overview of IPsec Policy Concepts."

Boundary Isolation Group Filter Action

To implement the Boundary isolation group, the Woodgrove Bank administrators created the IPSEC – Request Mode (Accept Inbound, Allow Outbound) filter action.

Woodgrove Bank has several business requirements regarding communication between hosts in the Boundary isolation group and other isolation groups. Accordingly, clients in the Boundary isolation group can perform the following actions described in tables 4.5 and 4.6 of Chapter 4:

In order to implement these requirements in an IPsec policy, you must design the filter action to work with the filter list that specifies all internal subnets. It is possible to reduce the listed requirements into two basic behaviors:

To meet the requirements for initiating and accepting traffic to or from the Isolation domain and the No Fallback isolation group, Woodgrove Bank ensured that the security negotiation methods used for the Isolation domain and No Fallback isolation group are present in the filter action. The common security negotiation method that Woodgrove selected is ESP with SHA-1 for integrity.

Hosts in the Boundary isolation group are allowed to communicate with untrusted systems. To facilitate this capability, the Woodgrove Bank administration team enabled both the Allow unsecured communication with non-IPsec-aware computers and Accept unsecured communication, but always respond with IPsec options for this filter action. By enabling both of these options, Woodgrove Bank ensured that the hosts will accept inbound unsecured traffic and be able to Fall back to clear for outbound unsecured traffic.

No Fallback Isolation Group Filter Action

To implement the No Fallback isolation group, the Woodgrove Bank administrators created the IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) filter action.

Woodgrove Bank has several business requirements for communication between hosts in the No Fallback isolation group and other isolation groups. Accordingly, clients in the No Fallback isolation group can perform the following actions:

Clients in the No Fallback isolation group can neither initiate communications to nor accept communications from untrusted systems.

To implement these requirements in an IPsec policy, you must design the filter action to work with the filter list that specifies all internal subnets. It is possible to reduce the listed requirements into two basic behaviors:

To enable communications with the Encryption isolation group, the security negotiation methods include the encryption negotiation methods that are defined for the Encryption isolation group. For more information about the encryption security negotiation methods, see the following "Encryption Isolation Group Filter Action" section in this chapter.

For traffic to the Boundary isolation group and No Fallback isolation group, Woodgrove Bank uses ESP with SHA-1 for the integrity security negotiation method.

The Accept unsecured communication, but always respond with IPsec checkbox on the filter action is cleared to create the No Fallback isolation group. This approach ensures that hosts in the No Fallback isolation group must secure all inbound and outbound traffic with IPsec. They will not accept traffic from any computer that is not participating in the IPsec environment.

The IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) filter action will not allow a computer that uses this filter action to initiate communication to a computer that does not participate in the IPsec infrastructure. The Allow unsecured communication with non-IPsec-aware computers option was disabled to enforce this requirement.

Encryption Isolation Group Filter Action

Woodgrove Bank chose ESP as its base integrity protocol and SHA-1 as the cryptographic option. In addition, hosts in the Encryption isolation group need to communicate with the hosts in the Isolation domain and No Fallback isolation group. The filter action was configured to include the security negotiation methods that encrypt the information.

Woodgrove Bank has several business requirements regarding the communication between hosts in the Encryption isolation group and other isolation groups. Accordingly, clients in the Encryption isolation group can perform the following actions from table 4.6:

Computers in the Encryption isolation group are prohibited from accepting communications from hosts in the Boundary isolation group.

To implement these requirements in an IPsec policy, the filter action must be designed to work with the filter list that specifies all internal subnets. It is possible to reduce the listed requirements into two basic behaviors:

Clients in the Encryption isolation group cannot accept communications from the Boundary isolation group and can neither initiate communications with nor accept communications from untrusted systems.

To enable communications with the Isolation domain, the encryption security negotiation methods used in the IPSEC – Require Encryption Mode (Ignore Inbound, Disallow Outbound) are also present in the IPSEC – Secure Request (Ignore Inbound, Allow Outbound) and the IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) filter actions. Woodgrove Bank uses the 3DES encryption method, which provides better security than DES but at the cost of additional overhead.

Because of the requirement to neither accept nor initiate communications with untrusted systems, Woodgrove Bank did not enable the Accept unsecured communication, but always respond with IPsec option. This configuration ensures that hosts in the Encryption isolation group will not accept traffic from any computer that is not participating in the IPsec environment. In addition, the Allow unsecured communication with non-IPsec-aware computers option was also disabled to prevent computers from attempting to initiate communications with any computer that was not participating in the IPsec environment.

Blocking IPsec communications from the Boundary isolation group computers required additional configuration. The Woodgrove Bank administrators configured the GPO that delivers the IPsec policy for the Encryption isolation group computers with the "Deny access to this computer from the network" right. This right was applied to a group that had all of the computer accounts for the systems participating in the Boundary isolation group. If any of these computers attempted to initiate communications with a system in the Encryption isolation group, the IKE authentication would result in an authorization failure, and the communication would be blocked.

IPsec Policies

IPsec policies configure Windows-based computers to function in an IPsec environment. An IPsec policy is a collection of rules against which traffic is matched. There are three different types of IPsec policy for Windows 2000:

Windows XP and Windows Server 2003 support the following additional policy types:

For simplicity, this guidance focuses on using Active Directory Domain IPsec Policy.

When defining IPsec policies, it is best to try to design a generic policy that will establish a foundation for the IPsec infrastructure for all computers. Then you can create additional policies to enforce more stringent settings on systems that need additional security configuration. You should design each additional policy to affect the greatest number of computers that need to meet the particular business or technical requirement. Keeping the total number of policies to a minimum will make it easier to troubleshoot and manage the policies.

IPsec policies comprise a name, description, set of rules, and configuration settings for polling intervals, key exchange settings, and key exchange methods, all of which the following section discusses in more detail.

Name

You should give policies, like filter actions, meaningful names to help in the management and troubleshooting of the solution during both the implementation and operations phases of the project.

Description

A detailed description of the policy will help administrators identify what the policy enforces without having to actually open the policy and study its rules.

Rules

An IPsec rule consists of a single filter list, an associated filter action, the authentication methods used to establish the trust between computers, the connection type, and whether the rule is a tunnel configuration.

Each rule defines one or more authentication methods to use for establishing trust between the hosts. The options are the Kerberos version 5 protocol, certificates from a specific certification authority, and preshared keys.

The connection type defines the connections to which the IPsec policy applies. You can configure the policy to apply to all connections, local area connections, or remote access-based connections.

The tunnel type defines whether the IPsec policy defines an IPsec tunnel. If the tunnel type is disabled, IPsec uses transport mode.

To support the security isolation groups identified earlier in this guide, Woodgrove Bank implemented four IPsec policies. It configured all four policies so that they used the Kerberos version 5 authentication protocol, applied to all connections, and did not define an IPsec tunnel.

The following table shows the policies used in the Woodgrove Bank scenario:

Table 5.6  Woodgrove Bank IPsec Policies

The number associated with each policy name is a version number and is discussed later in the "Policy Versioning" section.

Each of the Woodgrove Bank policies contains the same exemption lists, because there are no requirements for exempting a special set of computers for one particular isolation group. The following table shows the enabled rules that are the same across the four policies identified in the previous table:

Table 5.7  Common Rules Defined in Woodgrove Bank IPsec Policies

In addition to the rules listed in this table, the default client response rule in each of the policies is disabled.

The four policies that Woodgrove Bank defined only differ in how they handle the remaining traffic that is not handled by any of the exemption filter lists. For each of these rules, the authentication method is set to Kerberos version 5 protocol, the tunnel endpoint is set to None, and the connection type is set to All.

The following table shows the Woodgrove Bank rules for implementing the four isolation groups:

Table 5.8  Woodgrove Bank Base Rules for Implementing Isolation Groups

Woodgrove Bank chose to use the Kerberos version 5 protocol as its only authentication protocol. Woodgrove did not use preshared keys because the authentication key value can be read by local administrators in the registry, and by any authenticated user and computer in the domain. Woodgrove did not choose certificates because the bank does not have a deployed public key infrastructure (PKI).

By using the Kerberos version 5 protocol, all domain-joined computers are able to participate in the IPsec infrastructure because they can authenticate and obtain policy. Computers that are not joined to the domain are not able to easily participate in the IPsec environment because of the lack of an authentication mechanism and policy distribution system. If these computers meet trusted host criteria, you can configure an IPsec local policy using certificate authentication to enable them to communicate with other trusted hosts. Woodgrove Bank treats non-domain computers as untrusted at the current time.

Note   Using the Kerberos version 5 protocol for IKE authentication does not prevent non-domain-based computers from participating in the IPsec environment. For example, if a UNIX system is configured properly to use Active Directory as its Kerberos realm and the IKE implementation supports Kerberos authentication, then it may be possible for it to participate in the Isolation domain. However, such a configuration is beyond the scope of this document and has not been tested by Microsoft.

Polling Intervals

There are two polling intervals to consider: the Group Policy polling interval, and the IPsec service polling interval. The default setting for the IPsec service policy change polling interval is 180 minutes between consecutive polls for changes in Active Directory-based IPsec policies. These polls check only for changes in the IPsec policy, they do not detect changes in domain or organizational unit (OU) membership or the assignment or removal of an IPsec policy in a GPO. Changes to the computer's OU membership and assignment of GPOs are detected through the Group Policy service polling, which occurs every 90 minutes by default.

Woodgrove Bank chose to set both polling intervals to 60 minutes so that in case a security response was needed, policies could be updated and deployed within one hour to mitigate the risk. This increased polling frequency introduced additional polling traffic in the form of LDAP queries from the client to check the timestamps on the IPsec policies. Although this did not introduce a significant overhead in the Woodgrove Bank scenario, in deployments with a large number of clients, this increase may become significant.

Key Exchange Settings

The following key exchange settings define how new keys are derived and how often they are renewed. The term "master key" means the Diffie-Hellman shared secret key material generated in IKE main mode. The term "session key" refers to keys generated by IKE quick mode for use in the IPsec integrity and encryption algorithms. Session keys are derived from the master key.

Woodgrove Bank chose not to use Master key PFS because it did not have specific security requirements that required it. Similarly, IKE quick mode PFS was not used in the filter actions. The IKE main mode SA lifetime was changed from 480 minutes to 180 minutes to more quickly delete main mode SAs on busy servers in all but the Boundary isolation group. For the Boundary isolation group, Woodgrove Bank administrators reduced the IKE main mode SA lifetime to 20 minutes to reduce the attack surface presented by resident main mode SAs that were negotiated with the Encrypted isolation group. Although hosts in the Boundary isolation group cannot initiate new IKE negotiations with hosts in the Encrypted isolation group, the reverse can occur. After the main mode SA has been established, then a boundary host would be able to use this SA to negotiate quick mode SAs for the protection of inbound traffic to the corresponding system in the Encrypted isolation group until the main mode SA was deleted. This risk is reduced by forcing the main mode SAs on the boundary servers to be deleted more frequently. The number of sessions for which the master key can be used to generate a session key was left at the default setting of 0.

Key Exchange Methods

The key exchange methods control the security methods that are used during main mode IKE negotiation. The configuration options are for integrity (SHA-1 and MD5), confidentiality or encryption (3DES and DES), and the length of the base prime numbers used during the key exchange process.

Note   Computers running Windows 2000 must have the High Encryption Pack or SP2 (or later) installed to use 3DES.

The cryptographic strength of keys used for the integrity and encryption of the IKE negotiation itself and for IPsec data protection depends on the strength of the Diffie-Hellman group upon which the prime numbers are based. There are three options for the Diffie-Hellman group:

The High configuration can only be used with Windows XP SP2- and Windows Server 2003-based systems. The Medium configuration provides interoperability with Windows 2000 and Windows XP SP1. Low is provided for backward compatibility and should not be used because of its relative weakness.

The following table lists the key exchange security methods in order of preference that Woodgrove Bank chose to implement:

Table 5.9  Default Key Exchange Security Methods

Note   The use of the 2048-bit group in IPsec policy requires that the IPsec policy be configured using the Windows Server 2003 management tools, such as the IPsec Policy Management MMC snap-in or the Netsh IPsec command-line utility. This policy can be assigned in the domain to Windows 2000 platforms, which will ignore the 2048-bit option.

Policy Versioning

IPsec policy designs are likely to be changed many times throughout initial planning, lab testing, pilot deployments, and while in operational use. If you use scripts, spreadsheets, or other documents to create IPsec policies, you should manage these files with a version control system similar to Microsoft Visual SourceSafe®.

It is difficult to identify versions of IPsec policies within Active Directory by looking at the attributes on the policy. Troubleshooting steps will require the ability to determine which version of the IPsec policy is active on the computer. Therefore, it is recommended that you store some form of versioning information both within the name of the policy and within the policy rules.

A simple versioning method is to create a version ID based on the following formula:

<Major Change>.<Minor Change>.<Date:yymmdd>.<Time:24 Hour>

For example, 1.0.041001.1600 would be version 1.0 created on 10/01/04 at 4 P.M.

You should then place this version ID at the end of the name of the policy that you are creating. For example, IPSEC – Boundary IPsec Policy (1.0.041001.1600). You can also append it to the name or description of Filter Lists, which frequently change.

Group Policy retrieves the IPsec policy name, and it is stored in the local registry under HKEY_LOCAL_MACHINE \SOFTWARE\Policies\Microsoft\Windows\IPsec\GPTIPSECPolicy where it is stored as a string value under the DSIPSECPolicyName key.

Although IPsec service polling checks for changes in all assigned policy objects, it does not update the name of the assigned policy that Group Policy has stored. Group Policy does not update the name in the local registry until the GPO assignment is changed. Microsoft IT found that an unused rule within the IPsec policy can be an effective means of storing the policy version information. For example, you can create a filter list with a filter that contains invalid addresses and is associated with a permit filter action, such as the following:

Filter List Name: IPsec policy ver 1.0.041001.1600

Filter List Description: IPsec policy ver 1.0.041001.1600

1.1.1.1 <-> 1.1.1.2, ICMP, description = "IPsec policy ver ID 1.0.041001.1600"

After you create this filter list in Active Directory, you can identify the version object distinguished name (DN) for the filter list by using the Active Directory Users and Computers MMC running in Advanced mode. You can find the filter list object under the <DomainName>\System\IP Security tree and identify it by its description.

After you know the version object DN, you can compare it programmatically with the IPsec objects stored in the registry under HKEY_LOCAL_MACHINE \SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Cache to determine whether it is located in the cache. If you find the version object DN in cache, you can compare the policy names for the object stored in Active Directory and the object stored on the local computer. If the names are the same, the local and domain policies are synchronized. The names and descriptions of each IPsec filter list are also stored in the IPsec policy cache, which will help identify which versions of these objects are currently assigned. The IPsec service retains the text description for each filter (not filter list) in memory so that the IPsec monitor MMC snap-in and command-line tools can report this information.

A script can help automate the policy version check of a client, such as the example script Detect_IPsec_Policy.vbs, which is included in the Tools and Templates folder for this solution.

As policies are edited over a period of time, you should update the corresponding filter names to reflect the changes.

How to Apply IPsec Policies to Individual Computers

The final step to enabling IPsec is to deploy the policies to the hosts. There are two methods of deploying the policies. One method is to apply them directly to the individual host computers, and the second is through the use of GPOs and Active Directory. Policy application through Active Directory is discussed in the "How to Apply IPsec Policies Using GPOs" section later in this chapter.

You can accomplish the application of IPsec policies to individual computers in one of two ways: through the IPsec Security Policy Management MMC snap-in, or through the command line using Netsh (for Windows Server 2003), Ipseccmd.exe (for Windows XP), or Ipsecpol.exe (for Windows 2000).

The MMC snap-in provides a graphical user interface (GUI) that the administrator can use to manually apply policy or import a previously defined IPsec policy that was exported from another computer. In addition to manipulating the policy on the local computer, administrators can use the snap-in to manage policy on a remote computer.

Detailed information about the command-line tools is available from the following resources:

Microsoft provided updated IPseccmd and other support tools for Windows XP SP2. For more information see Microsoft Knowledge Base article 838079, "Windows XP Service Pack 2 Support Tools".

Detailed information about the use of these tools is beyond the scope of this guidance. The examples in this guide are geared toward using Netsh on servers running Windows Server 2003.

How to Apply IPsec Policies Using GPOs

Active Directory Group Policy is used as the IPsec policy assignment and distribution mechanism for domain-joined computers. Before distributing the policies through the Group Policy distribution mechanisms in Active Directory, you must first configure the GPOs that will be used to apply the IPsec policies to the host computers.

Note   Although the following section discusses loading IPsec policies directly into Active Directory, it is assumed that the policies were created and tested on a local system, in a test lab, and in small-scale pilot projects before being deployed to a production environment.

How to Load IPsec Policies into Active Directory

The first task in implementing IPsec policies through Active Directory is to create the filter lists, filter actions, and IPsec policies in the directory service. You can perform this task using the IPsec Security Policy Management MMC snap-in or a command-line tool such as Netsh. Regardless of which tool you select, you must perform the following three subtasks to implement the IPsec policies:

Using the IPsec Security Policy Management MMC Snap-in

The IPsec Security Policy Management MMC snap-in is a GUI-based tool that allows administrators to create, configure, and edit IPsec policies on local computers, remote computers, or domains. Configuration of the IPsec components is a manual process that involves direct editing of the objects being created and is guided by wizards.

After the IPsec policies are defined locally or in Active Directory, the administrator can export the IPsec policies (including all filter lists and filter actions) to a file ending with an .ipsec file name extension. You can copy this file to other media for backup purposes.

If a backup of the IPsec policies exists, you can use the tool to import the backed-up policies into Active Directory. You can use this approach for recovery purposes or to move IPsec policy files from a test forest into a production forest without having to recreate each filter list, filter action, and policy manually. Thoroughly review the design of policies that are restored from backup. Testing is recommended to assess the impact of applying old settings in the current environment. An old backup file may contain policy settings, such as filter lists, or filter actions, which are invalid and may cause communicate to fail if they were assigned to current domain members.

For more information about using the IPsec Security Policy Management MMC snap-in, see the topic "Define IPSec Policies" in the Help and Support Center in Windows Server 2003.

Using Netsh

You can use Netsh as an alternative to the IPsec Security Policy Management MMC snap-in for configuring IPsec polices within a Windows Server 2003-based Active Directory. You can run this command-line tool in an interactive mode or in batch mode. When used in interactive mode, Netsh requires the administrator to type individual commands into the Netsh command shell. Before creating the filter lists, filter actions, and IPsec policies, you must configure the tool to point to the Active Directory.

To point Netsh to the Active Directory, type the following command at the Netsh prompt:

ipsec static set store location=domain

The administrator then enters the filter lists, filters, filter actions, and IPsec policies manually through the Netsh command shell. Like the GUI tool, Netsh supports the export and import of IPsec policy files for backup and recovery scenarios.

Running Netsh in batch mode requires creation of a script file of Netsh commands. This script file must contain the command to set the focus on the domain as well as all of the configuration commands for the filter lists, filters, filter actions, and IPsec policies.

You can then create the IPsec policy information in Active Directory by launching Netsh and executing the script file. The command-line syntax for launching Netsh and executing a script file is as follows:

netsh –f <scriptfile>

For more information on using Netsh, see the "Netsh" topic in the "Administration and Scripting Tools" section of the Help and Support Center in Windows Server 2003.

Note   Netsh only works with IPsec policies on computers running Windows Server 2003. Command-line manipulation of IPsec policies on computers running Windows 2000 or Windows XP requires Ipsecpol.exe or Ipseccmd.exe, respectively. Also, Netsh lists a dump command in the IPsec context of the tool. This function is not implemented, although it is listed in the help text. In addition, unlike the GUI tool, Netsh does not support remote connections.

Creating Group Policy Objects for IPsec Policy Distribution

GPOs are objects stored within Active Directory that define a set of settings to be applied to a computer. IPsec policies are not stored within GPOs directly. Instead, GPOs maintain an LDAP DN link to the IPsec policy. IPsec policies are stored in the cn=IP Security, cn=System, dc=<domain> location within Active Directory.

GPOs are assigned to sites, domains, or OUs within Active Directory. Computers that are within those locations or containers receive the policy defined by the GPO unless it is otherwise blocked. The IPsec design team should consult with the Active Directory team to discuss the feasibility of using existing GPOs to deliver their IPsec policies. If this approach is not feasible or requires extensive modification of their management practices, new GPOs can be defined for each set of IPsec policies that will be deployed. The solution described in this guidance uses new GPOs for deployment of the IPsec policies.

Although GPOs can be created through Active Directory Users and Computers or the Active Directory Sites and Services tools, it is recommended that you create the new GPOs by using the Group Policy Management Console (GPMC). Creation of a policy through the Active Directory tools automatically links the GPO to the object that is being browsed. By using the GPMC to create the GPOs, the administrator can ensure that the GPOs are created within Active Directly but not applied to computers until each GPO is explicitly linked to a site, domain, or OU.

The GPMC is an add-on utility for computers running Windows XP Service Pack 1 (or later) or Windows Server 2003. The GPMC allows administrators to manage Group Policy for multiple domains and sites within one or more forests through a simplified user interface with drag-and-drop support. Key features include functionality such as backup, restore, import, copy, and reporting of GPOs. These operations are fully scriptable, which allows administrators to customize and automate management. Note that these GPO management techniques apply to managing IPsec policy objects themselves. You should develop a management strategy for managing IPsec policy in coordination with the GPOs that deliver the IPsec policy assignment.

For additional information about using the GPMC, see the white paper "Administering Group Policy with the GPMC".

You can download the Group Policy Management Console with Service Pack 1.

Using the GPMC, the administrator creates a GPO for each IPsec policy by completing the following steps:

To create a new GPO

As with IPsec filter actions and policies, you should develop a naming standard for the GPOs that includes a version number of the policy within the name—because version information of Active Directory objects is not easily obtainable. Inclusion of a version number in the policy name allows administrators to quickly identify the policy that is currently in effect. Microsoft recommends using the same naming convention that was described earlier in this chapter for filter actions and IPsec policies. For example, a GPO named "Isolation Domain IPsec GPO ver 1.0.040601.1600" would be version 1.0 created on 06/01/04 at 4 P.M.

After the GPO has been created, the administrator needs to configure it to use the appropriate IPsec policy.

To assign IPsec policy in a GPO

IPsec policy is applied to host computers through the computer configuration settings on the GPO. If the GPO is only used to apply IPsec policies, it is recommended that you configure the GPO to disable the user configuration settings. Disabling these settings will help shorten the processing time of the GPO by bypassing the evaluation of user configuration options.

To disable the user configuration on the GPO

If the user configuration settings are configured in the GPO at a later date, the administrator will have to re-enable the processing of user configuration settings for them to apply.

Domain Security Groups

Domain security groups serve two purposes. The first is to identify domain computer accounts that are members of an isolation group, and the second is to identify domain computer accounts that are members of a network access group.

All members of an isolation group are required to receive the same IPsec policy. Therefore, you can create domain security groups for application and management of the IPsec policies instead of using OU containers to control policy assignment. Universal groups are the best option to control policy assignment because they are applicable to the entire forest and reduce the number of groups that need to be managed. However, if universal groups are unavailable, you can use domain global groups instead. Domain local groups are used for network access groups discussed in a later section.

The following table lists the groups that were created for the Woodgrove Bank scenario to manage the IPsec environment and control policy application:

Table 5.10  IPsec Group Names

In addition to the listed groups, additional groups may have been created and used to restrict the policy application during the initial rollout. When deploying IPsec, it is not recommended to just create the GPOs and IPsec policies and assign them at the same time to all computers in the domain. A domain security group can be used for precise control over which computers can read th