Server and Domain Isolation Using IPsec and Group Policy
Appendix C: Lab Build Guide
This appendix provides complete guidance for building the required infrastructure to support isolation groups that use IPsec. This guidance discusses installation and configuration of Microsoft® Windows Server™ 2003, preparation of the Active Directory® directory service, and configuration of IPsec policy. This appendix also provides the implementation instructions that were used to roll out the baseline IPsec policy for the Woodgrove Bank scenario, which is described earlier in this guide. This appendix is intended to be used in conjunction with the other chapters in this guide, which explain the design process and rationale behind the implementation decisions that are used in this appendix. This appendix also explains the tasks and processes that are needed to successfully create and implement a baseline IPsec policy infrastructure. If you have not already done so, it is strongly recommended that you read the previous chapters before continuing with this appendix. You should also read and understand the implications of the support requirements detailed in Chapter 6, "Managing a Server and Domain Isolation Environment," before implementing the guidance in this appendix. On This PagePrerequisitesThis section contains information that will help you determine your organization's readiness to implement the solution. Knowledge PrerequisitesYou should be familiar with concepts of IPsec, networking, and network architectures. Familiarity with Windows Server 2003 is also required in the following areas:
Before proceeding with this appendix, you should also have read the planning guidance provided in this guide and have a thorough understanding of the architecture and design of the solution. Organizational PrerequisitesYou should consult with other people in your organization that may need to be involved in the implementation of this solution. Such people might include the following:
Note The structure of your IT organization will determine whether these roles may be filled by a number of people or whether fewer people span several roles. IT Infrastructure PrerequisitesThe appendix also assumes that the following IT infrastructure exists:
Baseline Implementation PrerequisitesBefore the tasks in this appendix are performed, there are a number of items that should be in place to ensure a successful deployment. Hardware RequirementsBefore the baseline IPsec infrastructure is rolled out, ensure that the current infrastructure is physically capable of supporting the overhead of the IPsec implementation. The process that will help you verify this capability is discussed in Chapter 3, "Determining the Current State of Your IT Infrastructure," of this guide. ToolsFour primary tools can be used to configure the IPsec policies and enable them through Active Directory GPOs. These tools are:
It is recommended that these tools be obtained and installed on the implementation team workstations so that team members can spend some time to familiarize themselves with the functionality of each tool before implementation begins. Deployment of the Baseline PolicyWoodgrove Bank chose to implement their deployment by first moving all computers into the Boundary isolation group by using the build-up method. This approach allowed administrators to move forward slowly and resolve any outstanding issues without significant impact on the communication between computers. By first deploying a policy without any secure subnets, the administration team was able to identify any computers that had a local IPsec policy assigned and consider that information. As subnets were added to the policy, any additional conflicts that were found were resolved. After the computers were operating under the Boundary Isolation Group Policy, the team moved on to implement the Standard, Outbound Clear Allowed, and Encryption isolation groups. These isolation groups were deployed by using the "deployment by group" method that is explained in Chapter 4, "Designing and Planning Isolation Groups," of this guide. A set of computers were selected for a pilot and added to the appropriate groups that controlled the new policies. Any issues were resolved and additional computers were added to the groups until the isolation groups were fully populated. Implementing the IPsec PoliciesThe process of getting the correct IPsec policy to each intended computer in a large organization can quickly become complex. The policy mechanism that is available in Active Directory can greatly simplify this process. The following sections in this appendix provide the information required to implement the IPsec policies. Copying Configuration ScriptsTo set up the IPsec policies, the first task is to copy the required configuration scripts to the domain controller that will be used to store them. The configuration scripts provided with the solution were used to configure the Woodgrove Bank lab. In the Woodgrove Bank scenario, the following steps were performed: To copy configuration scripts
Installing the Group Policy Management ConsoleThe GPMC is used to install and configure the GPOs that are used by the solution. The GPMC only needs to be installed on IPS-CH-DC-01; its installation on subsequent servers is optional. Note Installation of the GPMC slightly changes the user interface of the Active Directory Users and Computers MMC for the computer on which it is installed. For more information about using the GPMC, and to download the installation file, see the Group Policy Management Console with Service Pack 1 page on the Microsoft Download Center. To install the Group Policy Management Console
Implementing IPsec Filter Lists and Filter ActionsCreation of the IPsec filter lists and filter actions is accomplished by using either the Netsh tool or the IP Security Policy Management MMC snap-in. Although the IP Security Policy Management MMC snap-in provides a graphical interface for IPsec, many administrators find it easier to maintain and update scripts that use the Netsh command-line tool. In addition, the scripts can be easily ported across domains or forests. In this solution, Netsh scripts were used to implement the IPsec filter lists and filter actions. Note Test any scripts against the local policy stores on a computer that runs Windows Server 2003 by setting the store focus on local. After the scripts are debugged, modify the store configuration to focus on the domain for final import. To create the IPsec filter lists and filter actions
Note To test against local policy, ensure that the script being run in step 2 is configured with set store location=local. In step 3, ensure that the MMC snap-in is focused on the local computer rather than the domain. Implementing IPsec PoliciesAfter the filter lists and filter actions have been created, the scripts that create the IPsec policies can be run. Note The policies created by the scripts are configured with a polling interval of five minutes for testing purposes. The following table lists the policy name and the script file that creates the policy. This script file name will be used in step 2 of the following procedure. Table C.1 IPsec Policy to Script File Mapping
To create the IPsec policies
Note To test against local policy, ensure that the script being run in step 2 is configured with set store location=local. In step 3, ensure that the MMC snap-in is focused on the local computer rather than the domain. Creating GPOs for IPsec PoliciesWoodgrove Bank created four GPOs to deliver IPsec policies. Each of these GPOs was named after the IPsec policy to which it is assigned within the GPO. Until the policies are linked within Active Directory, these GPOs will not deliver any IPsec policies to the environment. The following table lists each GPO name and the IPsec policy name being delivered by that GPO. Table C.2 Woodgrove Bank GPO to IPsec Mapping
To create the GPOs for IPsec policies
Setting the Security on the IPsec Group PoliciesWoodgrove Bank used security ACLs on the GPO that contains the IPsec policies to control the application of the policies. The primary benefit was that the policies could be linked at the domain level rather than through multiple organizational units (OUs), which simplified the management of policy application. Furthermore, a staged roll out was implemented without moving any computer accounts to special OUs. Instead, the computer accounts that participated in the pilot were added to the appropriate groups. The drawback is that the organization must have good group management tools. Creating GroupsA set of groups was created to control how policy was applied throughout the Woodgrove Bank organization. Because the Woodgrove Bank forest was in Native mode, universal groups were used to control policy across all domains. Table C.3 Woodgrove Bank Universal Groups
To create the Woodgrove Bank universal groups
Configuring GPO SecurityGroups are used to control which computers get what policies for IPsec participation. The security ACLs need to be configured on each of the newly-created IPsec policies so that the appropriate groups are configured. The following table shows the ACLs to be added to each GPO. Note If an organization is going to delegate administrative rights to someone other than the Domain Admins group to manage IPsec policies, the delegated administrative group will need to be granted Full Control on the IP Security container in Active Directory. Table C.4 Woodgrove Bank Policy Group Permissions
Note The Boundary Isolation Group Policy is configured to allow the Domain Computers group to apply the policy for the initial build-up process by placing the Domain Computers group in the CG_BoundaryIG_computers group. After all computers are moved to their respective groups, domain computers will be removed from the CG_BoundaryIG_computers group. To set the group permissions on the GPO
Note Ensure that the entry for Authenticated Users was granted only Read permissions in the security ACL for each policy. If Apply permissions are also granted, the policy will be deployed to all computers. Blocking Boundary Isolation Group Computers from Initiating Connections to Encryption Isolation Group ComputersWoodgrove Bank required that computers in the Boundary isolation group be prevented from initiating communications with computers in the Encryption isolation group. To implement this restriction, a group called DNAG_EncryptionIG_computers is created to deny its members access to computers in the Encryption isolation group. The Encryption Isolation Group Policy was configured so that DNAG_EncryptionIG_computers was granted the "Deny access to this computer from the network" right, and the CG_BoundaryIG_computers group was placed in the DNAG_EncryptionIG_computers group. This configuration was accomplished by modifying the IPSEC – Encryption Isolation Group Policy GPO. To create the DNAG_EncryptionIG_computers group
To configure IPSEC – Encryption Isolation Group Policy to block members of DNAG_EncryptionIG_computers
To populate the DNAG_EncryptionIG_computers group with the CG_BoundaryIG_computers group
Adding Domain Computers to the Boundary GroupFor the initial deployment, the Boundary isolation group is used as the default isolation group for the IPsec-aware clients in the enterprise. The Domain Computers group is added to the CG_BoundaryIG_computers group to implement this plan. To add domain computers to the CG_BoundaryIG_computers Group
Note Because of replication delays and polling frequency of the IPsec policies, there will be a delay between the time the Domain Computers group is added to the CG_BoundaryIG_computers group and when the Boundary Isolation Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information. Adding Infrastructure Servers to the CG_NoIPSec_Computers GroupTo ensure that the infrastructure servers do not receive a policy that could interrupt communication (for example, if a server's IP address changes), the following infrastructure server computer accounts were added to the CG_NoIPsec_computers security group.
To add infrastructure servers to the CG_NoIPsec_computers group
Linking IPsec Policies and GPOs in a Domain EnvironmentBefore IPsec policies can be distributed, they need to be linked to locations within the domain environment. Because Woodgrove Bank chose to administer the GPOs through the use of security groups, the OU structure is not overly important to policy distribution. However, if there are OUs that block policy application, the IPsec GPOs would have to be linked directly to the OUs for the policy application to work. Another alternative might be to enable policy enforcement on the domain IPsec policy GPOs. To link the IPsec policies to the existing GPOs
Using the Policy Build-up Method to Enable the Baseline IPsec PolicyThe first task in the rollout of the IPsec infrastructure is the deployment of the Boundary Isolation Group Policy by using the policy build-up deployment method. Although the Boundary isolation group is not intended to be the Isolation Domain for all computers in the Woodgrove Bank environment, it is configured to apply to all computers for the first stage of the deployment. Because the Boundary Isolation Group Policy allows and accepts non-IPsec communication, it was deemed the safest policy to deploy gradually into the environment. The policy was initially deployed with no secure subnets defined. This allowed the Woodgrove Bank administrators to fix any existing local IPsec policies. Next, subnets are added one by one and tested to ensure that IPsec negotiation occurred correctly. Adding Subnets to the Secure Subnets Filter ListAfter the empty Boundary Isolation Group Policy was applied to the computers in the organization and any conflicts with existing local IPsec policies were resolved, Woodgrove Bank administrators began the build-up of the policy. The build-up of the policy consisted of identifying the organizational subnets to be secured. The identified subnets were added to the policy one by one. After adding the first entry to the filter list, the filter list is added to the policy. After each subnet was added, the policy was given time to apply to the computers in the organization and any conflicts were resolved. This process was repeated until the entire secure subnets filter list was deployed. The following table lists the identified secure subnets used in the lab at Woodgrove Bank to closely mirror their production network: Table C.6 Secure Subnets List for Woodgrove Bank Test Lab
To create the first entry in the secure subnets filter list
To add the secure subnet filter list to the Boundary Isolation Group Policy
To add the remaining subnets to the secure subnets filter list
Verifying the Baseline DeploymentAfter the policy objects are created and deployed into Active Directory in an inactive state, a process of verification should be undertaken before configuring the baseline policy to enforce the Baseline isolation group for all computers in the organization. Verification can help minimize any potential disruption to the participating hosts if there is an error in the baseline configuration. Functional Implementation TestsThe simplest test that can be performed to confirm IPsec functionality is to attempt to execute net view commands against computers that are in the secure organization network and against computers that are not in subnets listed in the secure organization network. Computers that are in a secure subnet should negotiate a hard SA that will be visible within the IP Security Monitor MMC snap-in. A soft SA should be created between an IPsec participant and a computer that is not in a subnet listed in the secure organization network. To test functionality of the IPsec policies that are applied
Test Tools and Scripts for the Functionality TestsA number of configuration settings must be monitored during the functionality tests. Although most of these settings can be monitored using standard tools, two tasks require tools with which a standard administrator might not be familiar. These tasks involve identifying the IPsec policy that is currently active on the computer and determining what type of SA was negotiated. Verifying IPsec Policy ApplicationDetermining which IPsec policy is active on a computer is a challenge because there is no consistent method that works across platforms. In some cases you can identify the IPsec policy through the graphical user interface (GUI), whereas other situations require a command-line tool that may or may not be installed with the operating system. Windows 2000For computers running Windows 2000 Server, the administrator can identify the currently applied IPsec policy by using the Netdiag command. To retrieve the policy name and information, the administrator logs on to the computer, launches a command prompt and types the following: Netdiag /test:IPsec The following is example output from this command: Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line. IP Security test . . . . . . . . . : Passed Directory IPsec Policy Active: ' IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600)' Windows XPFor computers running Windows XP, the administrator can identify the currently applied IPsec policy by using the IPseccmd.exe command-line tool. To retrieve the policy name and information, the administrator logs on to the computer, launches a command prompt and types the following: IPseccmd show gpo The following is example output from this command: Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line. Active Directory Policy
-----------------------
Directory Policy Name: IPSEC – Isolation Domain IPsec
Policy (1.0.041001.1600)
Description: Isolation Domain Policy (Allow Outbound)
Last Change: Fri Sep 03 15:20:29 2004
Group Policy Object: IPSEC – Isolation Domain Policy
Organizational Unit: LDAP://DC=americas,DC=woodgrovebank,
DC=com
Policy Path: LDAP://CN=IPsecPolicy{efa2185d-1a1d-40f6-b977-
314f152643ca},CN=IP Security,CN=System,DC=americas,DC=woodgrovebank,
DC=comWindows Server 2003For computers that run Windows Server 2003, the administrator can identify the currently applied IPsec policy by using the Netsh command-line tool. To retrieve the policy name and information, the administrator logs on to the computer, launches a command prompt and types the following: netsh IPsec static show gpoassignedpolicy The following is example output from this command: Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line. Source Machine : Local Computer GPO for <IPS-TZ-W2K-02>
GPO Name : IPSEC – Isolation Domain Policy
Local IPsec Policy Name : NONE
AD IPsec Policy Name : IPSEC – Isolation Domain IPsec
Policy (1.0.041001.1600)
AD Policy DN : LDAP://CN=IPsecPolicy
{efa2185d-1a1d-40f6-b977-314f152643ca},CN=IP Security,CN=System,
DC=americas,DC=woodgrovebank,DC=com
Local IPsec Policy Assigned: Yes, but AD Policy is OverridingUsing IP Security Monitor to Determine SA TypeThe IP Security Monitor MMC snap-in is used to examine the main mode and quick mode SAs, the associated filters, Internet Key Exchange (IKE) policies, and negotiation policies. During troubleshooting, the IP Security Monitor MMC snap-in can be used to determine what type of SA has been negotiated between peers. By examining the SAs under the Quick Mode tree, a system administrator can identify IPsec peers to the computer on which the tool is running. When a computer negotiates an IPsec connection, a hard SA is created. This SA will have some value other than <None> in one or more of the Authentication, ESP Confidential, or ESP Integrity fields. For example, ESP with SHA1 and no authentication would have HMAC-SHA1 under the ESP Integrity field, and <None> for the other two fields. If the hard SA also has negotiated encryption, the ESP Confidential field would contain either DES or 3DES. A soft SA will have <None> under all three fields, indicating that the responder fell back to clear. Enabling Organization Secure Subnets Filter List on Remaining PoliciesBefore you enable the IPsec policies that remain, the Secure Organization Network filter list needs to be added to each policy. This task is required because at the time of the policy creation, the Secure Organization Network filter list was empty and could not be added to the policy. Earlier in this appendix, the Secure Organization Network filter list was implemented and can now be added to the remaining policies. The following table shows the policy names and the associated filter action assigned to the Secure Organization Network filter list. Table C.7 Policy and Filter Actions Mapping
To add the Secure Organization Network filter list to IPsec policies
Enabling Network Access Group ConfigurationNetwork access groups are used to further restrict the IPsec responder to only accept connections from a select group of initiator computers and identified users. For example, by using network access groups, administrators can configure the executive client computers so that they only accept incoming traffic initiated from executive computers but still maintain their ability to initiate traffic to other resources. Note Care must be taken when you define this option because computers that need to initiate communication with computers in the network access group (for example, monitor systems that use polling) will fail if they are not included in the network access group. Implementing Network Access GroupsThe designers at Woodgrove Bank chose to implement network access groups through the use of domain local groups. These groups were then used to define the initiators. They granted the initiators group the "Access this computer from the network" right on the responders, and removed the Authenticated Users group from the right. Woodgrove Bank implemented the network access group by using domain local groups because these groups are stored in the session ticket, which refreshes every 60 minutes. If global or universal groups had been used, the network access group would have been stored in the ticket granting ticket (TGT), which has a lifetime of 8 hours. By using domain local groups, group changes take effect on a much timelier basis. Note Although this solution uses domain local groups with the "Access this computer from the network" right to implement the network access group, preshared keys or certificates could be used to implement individual network access groups. The designers at Woodgrove Bank identified one network group, which is used to control access in the Encryption isolation group. Creating Security Groups to Control AccessTable C.8 Woodgrove Bank Network Access Group Security Groups
To create the groups listed in the previous table
Adding Accounts to Network Access Group Security GroupsWoodgrove Bank added the identified computers that act as initiators of traffic within the network access group to the appropriate domain local groups that are used to implement the network access group. The following table lists the membership of the network access group that was identified by Woodgrove Bank. Table C.9 Woodgrove Bank Isolation Group Membership
To populate the group listed in the previous table
Adding User Accounts to Network Access Group Security GroupsWoodgrove Bank identified the user accounts that are authorized to initiate traffic within the network access group and added them to the appropriate domain local groups used to implement the network access group. The following table lists the membership of the network access group that was identified by Woodgrove Bank. Table C.10 Woodgrove Bank Network Access Group Membership
To populate the groups listed in the previous table
Creating a Group Policy Object to Grant the "Access This Computer from the Network" RightWoodgrove Bank created a GPO to enforce the defined network access group. Specifically, the GPO assigned the appropriate network access group security groups the "Access this computer from the network" right on the appropriate computers acting as responders. The administrators created the following table, which lists the GPO name and the associated group names used to implement the network access group. Table C.11 Woodgrove Bank Isolation Group Policy Definition
Note The listed groups are the minimum that should be added. The administrator will need to determine if any additional groups should be granted this right. To assign "Access this computer from the network" right
Linking Network Access Group Policy ObjectsBefore you distribute network access group policies, the GPOs need to be linked to a location within the domain environment. Woodgrove Bank chose to distribute the GPO by linking it to the appropriate OU in Active Directory, as shown in the following table. Table C.12 Network Access Group GPO Name and Target OU
To link a GPO policy to target OU
Verifying Deployment of Network Access GroupsAfter creating and deploying the network access groups and policy objects, administrators tested the functionality of the computers in the network access groups. Prerequisite Implementation TestsBefore it tested the functionality of the computers in the network access group, Woodgrove Bank confirmed that the user rights assignments were being updated appropriately. After sufficient time had passed for replication and policy update to occur, Woodgrove Bank performed the following steps on the computers listed in the following table. Table C.13 Network Access Group Membership
To confirm the correct group membership in the network access group
Functional Implementation TestsAfter Woodgrove Bank confirmed that the security groups were granted the appropriate user right, the computers that belonged to the network access groups were tested against each other. Woodgrove Bank used this information to confirm that the access right restrictions were in place and functioning. Woodgrove attempted to perform net view commands against various initiator and responder combinations. In addition to this test, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following table lists the initiator and responder for each execution of net view, indicates whether it should succeed or fail, and lists the type of SA negotiated. Table C.14 Network Access Group Functional Test Expected Results
To complete the functional test
Enabling the Isolation DomainBefore the Isolation Domain policies are rolled out, the administrator must identify a group of computers that will be used for the pilot test. Ideally, this group of computers should represent a cross-section of the organization's IT infrastructure and include both clients and servers. The identified computer accounts are added to the CG_IsolationDomain_computers group. After sufficient time has elapsed for replication, the Isolation Domain policy should apply to the pilot computers and take effect. Implementing the Isolation DomainWoodgrove Bank identified the following computers to be used in the pilot:
To add pilot computers to the CG_IsolationDomain_computers group
Note After the computers are added to the CG_IsolationDomain_computers universal group, sufficient time should be allowed for replication of the group membership changes throughout the forest and for the policy to apply to the hosts. Verifying Deployment of the Isolation DomainAfter the policy objects have been created and deployed into Active Directory in the active state, a process of verification should be undertaken to confirm that the computer functions properly within the isolation group. Prerequisite Implementation TestsBefore it ran any functional tests on the computer in the Isolation Domain, Woodgrove Bank confirmed sufficient time had passed for replication and policy update to occur and then that the correct IPsec policy was applied to it. To confirm that the correct IPsec policy was applied on IPS-TZ-XP-06
Functional Implementation TestsAfter Woodgrove Bank confirmed that the policy was applied to IPS-TZ-XP-06, the next step was to perform the some basic functional tests to ensure that the policy was operating as expected. Woodgrove Bank attempted to perform net view commands from IPS TZ-XP-06 to various computers in other isolation groups. In addition, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following table lists the target computers for each execution of net view, indicates whether it should succeed or fail, and lists the type of SA negotiated. Note When you attempt a net view command against an untrusted computer, you must pass credentials for the local administrator of the target computer. Table C.15 Isolation Domain Expected Functional Test Results
To perform the functional test on each target computer
Enabling the No Fallback Isolation GroupComputers placed in the No Fallback isolation group cannot initiate unauthenticated traffic to untrusted computers. Implementing the No Fallback Isolation GroupWoodgrove Bank placed those computers that cannot initiate unauthenticated communication to untrusted computers in the CG_NoFallbackIG_computers universal group. To populate the CG_NoFallbackIG_computers group
Note Because of replication delays and polling frequency of the IPsec policies, there will be a delay between the time the computer is added to the CG_NoFallbackIG_computers group and when the No Fallback Isolation Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information. Verifying Deployment of the No Fallback Isolation GroupAfter the policy objects have been created and deployed into Active Directory in the active state, a process of verification should be undertaken to confirm that the computer functions properly within the isolation group. Prerequisite Implementation TestsBefore it ran any functional tests on the computers in the No Fallback isolation group, and after sufficient time had passed for replication and policy update to occur, Woodgrove Bank confirmed that the correct IPsec policy was applied. To confirm that the correct IPsec policy was applied on IPS-LT-XP-01
Functional Implementation TestsAfter Woodgrove Bank confirmed that the policy was applying to IPS-LT-XP-01, the next step was to perform the some basic functional tests to ensure that the policy was operating as expected. Woodgrove Bank attempted to perform net view commands from IPS LT-XP-01 to various computers in other isolation groups. In addition to this, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following table lists the target computers for each execution of net view, indicates whether it should succeed or fail, and lists the type of SA negotiated. Note When you attempt a net view command against an untrusted computer, you must pass credentials for the local administrator of the target computer. Table C.16 Outbound Clear Allowed Expected Functional Test Results
To perform the functional test on each target computer
Enabling the Encryption Isolation GroupComputers that are placed in the Encryption isolation group require their traffic to be encrypted. In addition, servers that host data are configured to restrict who can access them through the network by implementation of an isolation group for the selected servers. By using an additional group policy and a security group, access to the server can be controlled by modifying the "Access this computer from the network" right. Care should be taken when changing rights on a server to ensure that legitimate users are not blocked from accessing it. Note The isolation group used in this section was implemented earlier in the "Enabling Isolation Group Configuration" section of this document. Implementing the Encryption Isolation GroupThe implementation team at Woodgrove Bank identified those computers that required IPsec encryption and placed them in the Require Encryption universal group. To populate the Require Encryption group
Note Because of replication delays and polling frequency of the IPsec policies, there will be delay between the time the computer is added to the CG_EncryptionIG_computers group and when the Encryption Isolation Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information. Verifying the Encryption Isolation Group DeploymentAfter the policy objects have been created and deployed into Active Directory in the active state, a process of verification should be undertaken to confirm that the computer functions properly within the isolation group. Prerequisite Implementation TestsBefore it ran any functional tests on the computer in the Encryption isolation group, and after sufficient time had passed for replication and policy update to occur, Woodgrove Bank confirmed that the correct IPsec policy was applied to the IPS SQL-DFS-01 and IPS-SQL-DFS-02 computers. To confirm that the correct IPsec policy was applied
Functional Implementation TestsAfter Woodgrove Bank confirmed that the policy was applied to IPS-SQL-DFS-01 and IPS-SQL-DFS-02, the next step was to perform some basic functional tests to ensure that the policy was operating as expected. Woodgrove attempted to perform net view commands against IPS-SQL-DFS-01 and IPS-SQL-DFS-02. In addition, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following tables list the target computers for execution of net view, whether it should succeed or fail, and lists the type of SA negotiated. Note When you attempt a net view command against an untrusted computer, you must pass credentials for the local administrator to the computer. Table C.17 IPS-SQL-DFS-01 Expected Functional Test Results
To test the functionality of the implementation on target computers
Enabling the Boundary Isolation GroupWoodgrove Bank placed the computers that must initiate or receive unauthenticated communication from untrusted computers in the CG_BoundaryIG_computers universal group. Implementing the Boundary Isolation GroupThe implementation team at Woodgrove Bank identified those computers that belonged to the Boundary isolation group and placed them in the CG_BoundaryIG_computers universal group. To populate the CG_BoundaryIG_computers group
Note Because of replication delays and polling frequency of the IPsec policies, there will be delay between the time the group is added to the CG_BoundaryIG_computers group and when the Boundary Isolation Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information. Verifying the Boundary Isolation Group DeploymentAfter the policy objects are created and deployed into Active Directory in the active state, a process of verification should be undertaken to confirm that the computer functions properly within the isolation group. |
