Server and Domain Isolation Using IPsec and Group Policy

This chapter provides complete guidance for defining isolation groups that fulfill the business security requirements discussed in Chapter 2, "Understanding Server and Domain Isolation." This solution uses a combination of the computer identity in the Active Directory® directory service domain, IPsec policy to authenticate this identity, and Microsoft® Windows® security policy to define and enforce isolation groups. Information technology (IT) administrators can use the concept of isolation groups to manage network traffic within their internal networks in a secure manner that is transparent to applications. This capability can significantly reduce the threat of damage from network-borne infections and attacks.

Through the Woodgrove Bank scenario, this guide shows the essential details of how an organization can turn its security requirements into deployed isolation groups. In addition, this guide shows how IPsec can be combined with other security settings to build a detailed, manageable, and scalable server and domain isolation solution.

Every business will have unique requirements for their solution, and the models in this guidance are not designed to be followed without question or modification. Organizations that use this guide will need to determine what is required and achievable for their own environments and make appropriate changes to the isolation group model design to ensure the best fit for their own business requirements.

On This Page

	Chapter Prerequisites
	Creating the Server and Domain Isolation Design
	Group Implementation Methods
	Group Implementation for Woodgrove Bank
	Summary

Chapter Prerequisites

This section contains information that will help you determine your organization's approach to the server and domain isolation solution. Successful completion of such a solution for your organization is dependent on the prerequisites identified in this section.

Knowledge Prerequisites

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

Before proceeding with this chapter, you should also have read the previous chapters in this guide.

Organizational Prerequisites

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

Note   Depending on the structure of your IT organization, these roles may be filled by a number of people, or fewer people may span several roles. However, it is important to identify a single point of contact to help coordinate the efforts of cross-organization teams through the various phases of the project.

This chapter also assumes that you have met the requirements listed in Chapter 2, "Understanding Server and Domain Isolation," and Chapter 3, "Determining the Current State of Your IT Infrastructure." These requirements include gathering information from the hosts, the network, and Active Directory. The gathering of business requirements and obtaining business sponsorship are also discussed.

Finally, you must have in place a plan to train the various help desk and support staff on the new concepts, terminologies, and technologies of this solution. Because this solution will affect many areas of the organization, support staff should be trained to handle any issues that arise during deployment.

IT Infrastructure Prerequisites

This chapter assumes that a Windows Server 2003 Active Directory domain infrastructure exists, running in mixed or native mode. This solution uses universal groups for Group Policy object application. If the organization is not running in mixed or native mode, it is still possible to apply the Group Policy object (GPO) through the use of standard global and local group configurations. However, because this option is more complex to manage, this solution does not use it.

Note   Windows Server 2003 introduced a number of improvements that affect IPsec policies. There is nothing specific to this solution that would keep it from working with Windows 2000. However, the solution was only tested using Windows Server 2003 Active Directory.

For more information about the enhancements made to IPsec in Windows Server 2003, see New features for IPSec.

Top of page

Creating the Server and Domain Isolation Design

The design of the solution depends heavily on the business requirements and the information gathered in the previous chapters. Chapter 2, "Understanding Server and Domain Isolation," and Appendix D: "IT Threat Categories," explain the components of the solution and identify the threats that it can and cannot address. Chapter 3, "Determining the Current State of Your IT Infrastructure," provides information about how to gather planning data, such as the current network architecture and host assets in the network. This chapter uses the information and requirements gathered for Woodgrove Bank, which are recorded in detail in Business_Requirements.xls (available in the Tools and Templates folder). You should reference this file during the design process that this chapter details to better understand the reasons behind the solution's design. The solution design process involves the following primary tasks:

The following sections explain each of these tasks.

Modeling Foundational Groups

For most implementations, it is recommended that you have a common starting point for the initial isolation groups. The following figure presents the two initial isolation groups that you should consider.

Figure 4.1 Foundation isolation groups

Foundational groups provide logical containers that are an excellent starting point for the isolation group design.

Untrusted Systems

Conceptually, the best place to start is with those computers that are not owned, managed, or even known to exist by the organization's IT department. These computers are generally referred to as untrusted or unmanaged hosts and are the first systems to identify in the design. These computers will not be part of the solution because they will not be able to use the domain-assigned IPsec policies.

Examples of computers that would fall into this group include:

Even if the native Windows IPsec service is running, the VPN client should permit IKE and IPsec communication end-to-end through the VPN tunnel connection. If end-to-end IPsec does not work through the VPN connection, it is possible to create an exemption for all IP subnets used for remote access. When this remote client reconnects to the internal network, it can again participate in the isolation solution.  

Isolation Domain

The isolation domain provides the first logical container for trusted hosts. The hosts in this group use IPsec policy to control the communications that are allowed to and from themselves. The term domain is used in this context to illustrate boundary of trust rather than to suggest a Windows domain. In this solution the two constructs are very similar because Windows domain authentication (Kerberos) is required for accepting inbound connections from trusted hosts. However, many Windows domains (or forests) may be linked with trust relationships to provide a single logical isolation domain. So they should not be considered one and the same.

The aim for the communications characteristics of the isolation domain is to provide the "normal" or standard rules for the majority of the organization's computers. In this way, for most implementations, an isolation domain will contain the largest number of computers. Other isolation groups can be created for the solution if their communication requirements are different from those of the isolation domain. Conceptually, an isolation domain is just a type of isolation group.

Boundary Group

In almost all organizations, there will be a number of workstations, or servers, that are unable to communicate using IPsec. For example, computers such as Mac or UNIX workstations are unlikely to be able to communicate using IPsec. Often, business requirements exist for these computers to communicate with trusted hosts in the isolation domain. Perhaps in an ideal world, all hosts on the internal network would be able to be trusted to the same level and to use IPsec, and the design would be simpler. However, the reality is that not all operating systems provide the same degree of support for IPsec.

The recommended way to deal with this situation is to create an isolation group (referred to as the Boundary group in this guide) that contains hosts that will be allowed to communicate with untrusted systems. These hosts will be exposed to a higher level of risk because they are able to receive incoming communications directly from untrusted computers.

Computers in the Boundary group are trusted hosts that can communicate both with other trusted hosts and with untrusted hosts. Boundary hosts will attempt to communicate using IPsec by initiating an IKE negotiation to the originating computer. If no IKE response is received within three seconds, the host will Fall back to clear and begin attempting to establish communications in plaintext without IPsec. Because these Boundary group hosts will be allowed to communicate with trusted hosts that use IPsec-secured network communications and untrusted hosts that use fall back to clear, they must be highly secured in other ways. Understanding and mitigating this additional risk should be an important part of the process of deciding whether to place a computer in the Boundary group. For example, setting up a formal business justification process for each computer before agreeing to place it in this group can help ensure that all interested parties understand why the additional risk is required. The following figure illustrates a sample process that can help make such a decision.

Figure 4.2  Boundary Group Membership Justification Process
See full-sized image

The goal of this process is to determine whether the risk of adding a host to the Boundary group can be mitigated to a level that makes it acceptable to the organization. Ultimately, it should be assumed that if the risk cannot be mitigated, membership should be denied.

Creating Exemptions Lists

The server and domain isolation security models all run into a few constraints when they are implemented in a live environment. Key infrastructure servers such as domain controllers, DNS servers, and Dynamic Host Configuration Protocol (DHCP) servers are usually available to all systems on the internal network. Clearly they must be secured to the maximum extent possible from network attacks. However, because they are available to all systems on the network, not just to domain members, these server services cannot require IPsec for inbound access, nor can they take advantage of using IPsec transport mode protection for all of their traffic. Because a three-second fall back to clear for access to these services, particularly DNS, would severely impact the performance of all internal network access, they are not candidates for the Boundary group. Also, trusted hosts require access to the DHCP server to get an Internet Protocol (IP) address during computer startup or when the network cable or card is plugged in to a mobile computer. Trusted hosts also require DNS to locate the domain controllers so they can log on to the domain and receive Kerberos credentials. Therefore, a list of servers and services (protocols) that are exempt from using IPsec will be required for IPsec to work properly, as well as to permit all internal hosts to share the common internal network infrastructure. The list of computers that cannot be secured with IPsec is called an exemption list and is implemented in each IPsec policy designed. There may also be other servers on the network that trusted hosts cannot use IPsec to access, which would be added to the exemption list. Generally, the following conditions might cause a host to be in the exemptions list:

The IPsec implementation in Windows supports only static filtering, not dynamic (or stateful) filtering. Therefore, a static exemption for outbound traffic is also a static exemption for inbound traffic. Exempted hosts therefore have unauthenticated inbound access to every host, trusted or untrusted. Thus, the number of exempted hosts must be kept to a minimum, and these hosts must be closely managed and hardened as much as possible against attacks and infections. To help mitigate the risk of inbound attacks from hosts in the exemption list, a host-based stateful filtering firewall, such as Windows Firewall, can be used. Windows XP Service Pack (SP) 2 provided domain-based Group Policy controls for configuring the firewall. Windows Firewall also supports the capability to authorize only certain computers through the firewall when protected by IPsec, using the policy setting "Windows Firewall: Allow authenticated IPsec bypass." Woodgrove Bank chose not to implement Windows Firewall capability. However, other environments may find it necessary to achieve high levels of security within an isolated domain or group. For more information, see the “Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2” white paper on the Microsoft Download Center.

For large organizations, the list of exemptions may grow quite large if all the exemptions are implemented by one IPsec policy for the entire domain or for all trusted forests. A large list has a number of unwanted effects on every computer that receives the policy, including the following:

To keep the number of exemptions as small as possible, several options exist:

As with defining the Boundary group, there should be a formal process to approve hosts being added to the exemption list. Refer to the decision flow in the previous figure as a model for processing requests for exemptions.

Planning the Computer and Network Access Groups

The isolation domain and each isolation group must have clear and complete specifications of network security requirements. The Business_Requirements.xls spreadsheet in the Tools and Templates folder provides a model for how requirements can be documented. After inbound and outbound requirements are documented, you can design the mechanisms for implementing access controls.

At this point in the process, you should start a record of the new Active Directory groups that will be required to support the isolation group requirements. For each isolation group, you will need to create up to three specialized Active Directory groups. The following section explains the role of each of these groups.

Computer Groups

Each isolation group will require a computer group to be created that will be used to contain the members of the isolation group. This is required because the security requirements for an isolation group are met by several types of security settings in GPOs assigned in the domain. For example, this solution uses security group filtering on the GPOs to deliver an IPsec policy to the computers in a particular isolation group. Computer accounts that are members of the computer group will be assigned the associated IPsec policy when the GPO is processed. This is to avoid having to change or create a new organizational unit (OU) structure based on isolation group membership to apply the proper GPOs. If the OU structure can be changed to reflect the isolation group membership, these computer security groups are not needed to control the application of Group Policy.

Table 4.1  Woodgrove Bank Computer Groups

Network Access Groups

Using IPsec and Kerberos alone provides a trusted and untrusted authentication boundary. To help differentiate this group from any other groups, this guide refers to these groups as network access groups (NAG).

There are two types of NAGs that you can create: Allow and Deny. It is these groups that control the ability of other trusted systems to either explicitly allow or deny access. You achieve this control by using either the "Deny access to this computer from the network" (DENY) or the "Access this computer from the network" (ALLOW) user right in Group Policy.

Technically, this user right access control only applies to network services that receive logon credentials to authenticate the account for network logon. The "account" may be a computer, user, or service account. When IPsec policy is configured to protect all traffic IKE will confirm that the remote computer has a network logon right. Therefore, the network logon right now controls the ability for a remote computer to make any IPsec protected connections. After this IP-level access control has been checked, the normal upper layer protocols (for example, file sharing) typically authenticate the user, which again evaluates the network logon rights of the user identity. Finally, service-specific permissions (such as file share access control lists) are evaluated using the user identity. For more information, see the Network Access Control Layers diagram in Chapter 2, "Understanding Server and Domain Isolation."

By default, the ALLOW user right contains the Everyone group, which allows all authenticated users and computers to access the computer. During the implementation of this solution, the Everyone group will be replaced through Group Policy user rights assignment with NAGs that contain specific computers or users and groups, depending on organizational requirements. Likewise, the DENY user right will have computers that are not supposed to have IPsec-protected inbound access. Although it is possible to use a single group to contain user and computer accounts, Microsoft recommends using separate groups, one for users and one for computers. This approach improves the ability to manage and support these policies and groups on an ongoing basis. The configuration of user rights assignment for ALLOW and DENY supplements the guidance that earlier Windows platform security guides provide, because those guides did not specifically accommodate computer authentication that IPsec requires.

The requirements that NAGs might implement include the following:

In the Woodgrove Bank scenario, one business requirement set a limit on the amount of new computer hardware that could be purchased for the year. A print server was needed to allow both trusted hosts and untrusted hosts to print. Although Woodgrove would have preferred to purchase a new server that only untrusted computers would use for printing, Woodgrove decided that one server could fulfill the needs of both types of hosts. Therefore, it created a boundary server as a print server. Because the print server was at higher risk of being infected and attacked from untrusted computers, the rest of the trusted hosts would need to block inbound access from that server. Trusted hosts would still be able to make outbound connections to the print server when needed. Accordingly, Woodgrove determined that it needed a DENY NAG to implement this requirement.

At this stage of the design process, assigning NAG membership is not required. All that is needed is to identify and document the NAGs that the design will require. The designers at Woodgrove Bank identified a need for the following NAG:

Table 4.2  Woodgrove Bank Network Access Groups

Creating Additional Isolation Groups

At this point in the design process, there are two isolation groups: the isolation domain and the boundary group.

If your organization's business requirements can be satisfied by this design, you can continue to the next section of this chapter to define the traffic models for these two isolation groups. However, if your organization requires some trusted hosts to have different inbound or outbound network access controls or traffic protection, isolation groups will be required for each different set of requirements.

The purpose of this section is to help you understand when additional groups will be required. The first thing to do is to identify which computers have specific isolation or traffic protection requirements that are not met by the settings for the isolation domain. The goal should be to keep the number of these hosts to a minimum, because each new group will increase the complexity of the overall design and therefore make it more difficult to support and manage.

Typical examples of requirements that might lead to creation of a new group include the following:

In many cases, the inbound access requirements of servers that contain high value data are to allow only a subset of trusted hosts in the domain to connect. In other cases, trusted hosts might not be allowed to make outbound connections to untrusted computers to reduce the risk of information leakage or to enforce regulatory compliance for the protection of network traffic. For example, in the Woodgrove Bank scenario, the designers identified requirements that could only be fulfilled by the creation of the following two additional isolation groups:

Although the second group has a no fallback requirement, they do not have the full set of requirements that the applications servers do. Thus, these two different sets of requirements indicated that two additional isolation groups were required. These additional groups brought the total group count for Woodgrove Bank to four. The following figure shows how these groups looked in the final Woodgrove Bank isolation group design:

Figure 4.3  Final Woodgrove Bank group design

The following four groups require policy to achieve the design requirements:

Because Woodgrove Bank identified two additional groups that require IPsec policies, it defined additional computer groups to control the application of these newly identified policies.

Table 4.3  Additional Woodgrove Bank Computer Groups

Accordingly, Woodgrove determined that it would need NAGs to authorize inbound access for the subset of trusted hosts. The designers at Woodgrove Bank created the following NAGs:

Table 4.4  Woodgrove Bank Network Access Groups

Gathering Network Traffic Requirements

At this point in the design process, you should document the communications traffic requirements that will be allowed to pass between the groups, along with the form that the communications will take. There are many ways to record the traffic requirements for the groups. However, the Microsoft IT support team found, as part of their own experience, the creation of a diagram was the best method for communication of the exact requirements.

The following figure depicts the communications paths that are typically allowed between the foundational groups, the untrusted hosts, and the exemptions lists. To simplify this model, the exemptions lists are shown as a single grouping. This is typically the case for infrastructure services, such as Domain Controllers or DNS servers. However, isolation groups may have a business requirement to exempt specific computers just for the computers in that group. In these cases, the isolation group would then contain an additional exemption list of the computers that are to be exempted in addition to the common exemptions. Microsoft recommends keeping the exemption list entries to a minimum because they explicitly exempt systems from participating in the IPsec infrastructure. In the figure, all arrows shown in a solid black line use IPsec for their communications; the dotted lines indicate communications that are allowed to occur without IPsec. Groups that are depicted with a bold dashed line have an IPsec policy assigned to the computers in that group.

Figure 4.4  Typical allowed communications paths for foundational isolation groups
See full-sized image

The following table records the allowed communications paths for the traffic among the foundational groups, unsecured systems, and the exemptions lists:

Table 4.5  Allowed Communication Options for Foundational Isolation Groups

The previous table records the communications requirements for each allowed communications path in the initial isolation group design. The following list explains each column:

The short forms of the group names were used to keep the information in the table as concise as possible. By using this form of documentation, it is possible to create a very concise representation of the solution's communications. By assuming that all network traffic is disallowed unless specifically identified in this table, the process of identifying the traffic that will be protected as part of the solution becomes much clearer. In the example shown in the previous figure, each of the following allowed paths is explained:

After the foundational communications have been documented, additional groups can be added to the overall plan and their communications requirements recorded in the same way. For example, the two additional groups required by the Woodgrove Bank scenario led to a more complex communications diagram, as shown in the following figure.

Figure 4.5  Woodgrove Bank-allowed communications paths for isolation groups
See full-sized image

The following table records the allowed communications paths for the traffic in the additional groups for the Woodgrove Bank scenario.

Table 4.6  Allowed Communication Options for Additional Isolation Groups

In the example shown in the previous figure and described in the previous table, each of the following additional allowed paths is explained:

As this example illustrates, adding groups can have an exponential impact on the complexity of the solution. For this reason, it is recommended that the number of groups be kept to a minimum, especially during the early stages of a deployment when the most change is being introduced.

Assigning Computer Group and Network Access Group Memberships

After the traffic requirements are detailed and documented in the design, the next task is to identify which hosts will be members of which computer group or NAG.

As mentioned previously, computer groups are used in this solution to apply the GPO that contains the associated IPsec policy. After determining that a computer must belong to a particular isolation group, that computer's account is added to the computer group for that isolation group. For the isolation domain, this step is not required, because all domain computers implicitly belong in the isolation domain computer group.

Membership in a NAG will be based on the inbound authorization that the NAG implements. For example, if a NAG exists to restrict communication for a particular server to a known set of clients, the client computer accounts need to be placed in the appropriate NAG. NAGs are only created when needed, and therefore they have no default configuration.

Computer Group Membership

It is important that a host should not be represented in more than one computer group, because the computer group is used to control which GPOs apply. Although it might be theoretically possible to modify the policies to allow a host to belong to more than one computer group, the complexity of such an approach would rapidly make the solution unsupportable.

Generally, this task of determining computer group membership is not complicated, but it can be time consuming. You should use the information generated from an audit such as the one performed in Chapter 3, "Determining the Current State of Your IT Infrastructure," of this guide to place each host into one computer group based on the isolation group membership of that host. You can determine this placement by adding a Group column to record the computer group membership for the final design, as shown in the following table:

Table 4.7  Sample Host Collection Data

Network Access Group Membership

The final step in this design process is to populate the membership of the NAGs identified earlier in this chapter. Although a trusted host should only belong to one computer group, it is possible for a trusted host to be a member of multiple NAGs. Try to use as few NAGs as possible to limit the complexity of the solution.

When assigning membership to a NAG for user accounts, decide how tightly you want to control the access. For a resource that is already using standard share and file permissions to ensure the correct level of control, the simplest way to assign membership would be to assign the user's NAG membership to Domain Users from each trusted domain in the forest that requires access to the resource. This approach almost restores the behavior of the original default value of Authenticated Users but does not include local user accounts. If local user or service accounts are required, then a domain-based GPO may not be the best approach to configure ALLOW and DENY network logon rights. The ALLOW and DENY user rights assignment do not merge settings among several GPOs. Therefore, this computer should be prevented from having the domain-based GPO assigned for ALLOW and DENY and should use a customized local GPO. If the domain-based GPO that delivers IPsec policy assignment is different from the GPO used to deliver network logon rights, the domain-based GPO for IPsec policy assignment can still be used.

In addition, decide how to implement the inbound access requirements using either an ALLOW NAG or a DENY NAG or both. Deciding which type of NAG to create is based solely on what the intended behavior is and what minimizes administrative effort. It may be helpful to have a pre-existing but empty DENY NAG for users and a DENY NAG for computers already populated in the GPO "Deny access to this computer from the network" right.

For high-security scenarios, the membership of user NAGs can be assigned to specific users or groups. If this method is used, it should be understood that users who are not members of this group will be blocked from accessing the computer over the network, even if they are members of the local administrators group and have full control on all share and file permissions.

For the Woodgrove Bank scenario, NAG_EncryptedResourceAccess_Users membership was assigned to Domain Users and recorded as shown in the following table:

Table 4.8  Woodgrove Bank Network Access Groups with Membership Assigned

Note   Membership in a NAG does not control the level of IPsec traffic protection. IPsec policy settings control the security methods used for protecting traffic and are independent of the identity being authenticated by IKE. The IKE negotiation is only aware of whether the Kerberos computer identity passed or failed the authentication process. It cannot implement a policy of "encrypt if user3 connects" or "encrypt if trusted host IPS-SQL-DFS-01 or IPS-SQL-DFS-02". The administrator must achieve the intended behavior by using an IPsec policy for the servers in the Encryption isolation group that requires "encryption for any inbound trusted host connection" and likewise requires "encryption for any outbound connection to a trusted host."

So far, this design process has not reviewed the details of the IPsec policy design. Chapter 5 will provide details of the IPsec policy design for Woodgrove.

At this point in the design process, you have completed the tasks that are required to turn your requirements into a draft design. This section has helped you develop both the design and the documentation that will be required for the creation of the IPsec policies.

Limitations That Might Affect Your Design

The following issues might affect your design and therefore must be considered before your design can be considered complete:

Although these articles mention users specifically, the issue also exists for computer accounts, because the Kerberos MaxTokenSize also applies to computer accounts. Although this limit should rarely be reached in most implementations, you need to be aware of this issue if you decide to put one computer (perhaps a client) in a large number of NAGs.

If your design will be affected by these issues, you will need to revisit the design process to address them. For example, you could address the maximum number of concurrent connections issue by moving a very heavily loaded server into the Exemptions lists. You could address the maximum Kerberos token size limitation by reducing the number of NAGs your design will use.

If these limitations will not affect your design, the next task is to consider how the design will be deployed into the organization.

Top of page

Group Implementation Methods

After you have created the initial design, you must carefully consider the process of deploying IPsec. Only in the smallest environments is it possible to simply deploy the policies to all computers and expect IPsec to work smoothly with an acceptably small impact on users.

In large organizations, complexity and risk necessitate a phased deployment strategy. By using such an approach, the organization can help mitigate the risk associated with such a fundamental change to the environment. Without careful planning, help desk calls and lost productivity will quickly increase the cost of deployment.

There are a number of ways to deploy IPsec in an organization. Some of the factors that help determine the deployment method include:

The following deployment methods are not all inclusive but provide examples of possible approaches that you could take. You can also use a combination of these approaches. Generally, organizations should not deploy IPsec policies that restrict or block communication initially to ensure that adequate time is available to troubleshoot problems and to reduce the management coordination for complex environments.

Regardless of which approach is used to deploy IPsec, it is highly recommended that the deployment scenario be thoroughly tested in a lab environment, including the specific sequence and timing of rollout steps and policy changes. In addition, use a filter action that requests IPsec functionality but will accept plaintext communication by using Fall back to clear. This approach will help minimize the impact of the initial rollout. After the roll out is complete, move towards more secure modes of operation that require the traffic to be protected by IPsec.

For deployment in a production environment, an initial pilot is strongly recommended for each major phase of the rollout. It is particularly important to analyze the impact of IPsec policy changes, because they will take effect in the production environment as a result of Kerberos ticket lifetimes, Group Policy polling intervals, and IPsec policy polling intervals. You should implement a formal change control process with rollback strategies and rollback criteria to ensure that all affected IT organizations are aware of the change and its impact and know how to coordinate feedback to decision makers.

Deploy by Group

The Deploy by Group method uses fully-defined IPsec policies but controls the application of the policies through the use of groups and ACLs on the GPOs that deliver the policies.

In the Deploy by group method, the IPsec policies are created in Active Directory in their final configuration. Each IPsec policy has all of the exemptions and secure subnets defined with the appropriate filter actions enabled.

Then the IPsec policy administrators create GPOs for each IPsec policy. In addition, computer groups are created in the domain to manage and apply these newly created GPOs. The ACLs on the GPOs are modified so that members of Authenticated Users no longer have the "Apply" right. The appropriate administrator user groups for management and application of the policy are also granted rights to the GPO.

Next, the appropriate IPsec policies are assigned to their corresponding GPO. In addition, the GPO is linked to the appropriate object in Active Directory. At this point in time, none of the computers in the environment should receive the policy, because the ACLs that control the assignment of the GPO (the ability to read the GPO) are empty.

Finally, the computers that will receive the policies are identified and their computer accounts are placed in the appropriate computer groups with read access to the GPO. After the computer's Kerberos tickets are updated with the group membership information, the GPO, along with the corresponding IPsec policy, will apply at the next Group Policy polling interval.

Note   ACLs that restrict domain computers from reading the IPsec policy objects or the IPsec policy container in Active Directory are not recommended.

Consider an organization that has two IPsec policies defined, IPsec Standard and IPsec Encryption. The IPsec Standard policy is its default policy that requires incoming traffic to use IPsec but will allow the systems to Fall back to clear if they initiate to a non-IPsec-based computer. The IPsec Encryption policy requires encrypted IPsec to be negotiated at all times.

In this example, the organization's administration creates two GPOs in Active Directory: Standard IPsec GPO and Encrypted IPsec GPO. In addition, they identify the groups in the following table:

Table 4.9  IPsec Administration Groups

The ACLs on the two newly created GPOs are updated so that they do not automatically get applied to the Authenticated Users group and so that the appropriate application groups and management groups are given the correct rights. The administration modified the ACLs for the two GPOs according to the information in the following table:

Table 4.10  Group Rights on GPOs

Note   This table only shows permissions that are added or modified. There will be some additional groups with permissions, as well.

The administrators linked the two GPOs to the domain in Active Directory. This approach ensures that the policy will apply on any computer in the domain without modifying its location (unless the computer is located in an OU that blocks policies).

As computers are identified, their computer accounts are added to either the IPsecSTD group or the IPsecEnc group. After a period of time, the corresponding IPsec policy will apply and be in effect.

This method requires careful planning to ensure that communications are not disrupted. For example, if a server was placed in the IPsecEnc group, but multiple clients that depended on that server could not negotiate IPsec, communications between those clients and server would be disrupted.

Deploy by Policy Buildup

This deployment method uses a technique in which the IPsec policies can be built from scratch during the deployment. The advantage to this method is that IPsec is negotiated only for a small percentage of the total TCP/IP traffic, instead of for all internal subnets in the deploy-by-group method. It also allows the testing of all network paths in the internal network to this target subnet to be sure there are no problems with the network passing IKE negotiation and IPsec protected traffic. A further advantage is that the polling interval for IPsec can more quickly deliver IPsec policy updates (including rollback) instead of having to depend on group membership changes in the Kerberos Ticket Granting Ticket (TGT) or service tickets. The disadvantage to this method is that it applies to all computers in the isolation domain or group, not to specific computers as in the Deploy by Group Method. Also, all computers will have a three-second delay for Fall back to clear at some point when communicating to the specified subnets.

In this deployment method, IPsec policies only include exceptions initially; no rules exist for computers to negotiate security in the IPsec policy. This method first tests and ensures that any previously existing local IPsec policies that might be in use are removed. The administration team should be able to identify hosts that were using locally defined IPsec policies in advance to manage those systems with a special process. If a local IPsec policy is overridden by a domain policy, there could be interruptions in communications and a loss of security for the affected computers. Unlike local policies that are overwritten by the domain policy application, persistent policies on Windows Server 2003 merge with the result of the application of the domain policy. A system that contains a persistent policy might appear to work, but the configuration of the persistent policy can change the behavior or actually lessen the security that the domain policy provides or can disrupt the communications after secure subnet rules are added to the policy.

Next, you can create a security rule with a filter that affects only a single subnet within the organization's network, for example "From Any IP to Subnet A all traffic, negotiate." This rule would have a filter action to accept inbound plaintext and trigger negotiations for all outbound traffic to that subnet with Fall back to clear enabled. As the rollout in all domains of this IPsec policy takes effect, communications will gradually go from soft SAs to normal IPsec security associations for trusted hosts just on that subnet. Any IKE negotiation failures are investigated and resolved. Any application incompatibilities are identified and fixed. IPsec will secure communication between trusted hosts within that subnet. Communication with trusted hosts outside that subnet will Fall back to clear after the three-second delay. Additional subnets are added to the secure rule until the policy is built up to its final state.

Consider an organization that has a single IPsec policy defined, which is called IPsec Standard policy, which requests IPsec negotiation but failing that will Fall back to clear text communication. The policy is created in Active Directory, and it contains only exemption rules.

The Standard IPsec GPO is created and linked so that it applies to all computers in the environment. In addition, the IPsec Standard policy is assigned to this new GPO.

All computers will eventually be assigned the IPsec policy. Any issues with local IPsec policies will be discovered because this domain policy will override the existing local policies. Issues are continually resolved until all subnets are listed in the Secure Subnets filter list.

Top of page

Group Implementation for Woodgrove Bank

Woodgrove Bank chose to implement its production deployment by first moving all computers to the Boundary group using the buildup method. This approach allowed administrators to move forward slowly and resolve any outstanding issues without significantly affecting the communications between all systems. By first deploying a policy without any secure subnets, the administration team was able to identify any systems that had a local IPsec policy assigned and take that information for additional consideration. As subnets were added to the policy, any additional conflicts that were found were resolved.

After the computers were operating under the Boundary group policy, the team implemented the Isolation domain, No fallback, and Encryption groups. Deployment of these groups used the Deploy by Group method. A set of computers were selected for a pilot and added to the appropriate groups that controlled the new policies. Issues were resolved as they were discovered, and additional computers were added to the groups until the groups were fully populated.

The following table lists the computer groups and NAGs and their membership after the solution is fully deployed:

Table 4.11  Computer and Network Access Group Membership

Notice that the ANAG_EncryptedResourceAccess_Computers group contains the servers that are in the encryption isolation group. This is so they will be able to communicate with themselves and each other as required. If this communication is not required for these servers, you do not need to add them into this group.

Top of page

Summary

This chapter described the design process for a server and domain isolation solution. Tasks included identifying the need for computer groups and NAGs, understanding the foundational isolation groups, adding additional isolation groups, completing a traffic model, assigning membership to the groups, and planning the deployment rollout method.

This chapter also used the IPsec implementation at Woodgrove Bank, a fictitious organization, to help illustrate the design process in action and to prove the design in the Microsoft test labs.

Group design was based on business requirements and the discovery information obtained from the previous two chapters and documented in the Business_Requirements.xls spreadsheet (available in the Tools and Templates folder). An appreciation for the impact of IPsec on a network was also an important consideration.

After reading this chapter, you should have enough information to start planning isolation groups, documenting the communication requirements between those groups, and planning the high-level IPsec policy. These tasks will prepare you for Chapter 5, "Creating IPsec Policies for Isolation Groups."

More Information

This section provides links to additional information that may be helpful when implementing this solution.

IPsec

The following links provide a wide range of Windows-specific IPsec content:

Security

Windows Server 2003 Active Directory

For more information about Active Directory, see:

Top of page

5 of 14