Protect Confidential Information Using IPSec and Group Policy – Part 2

In my last article, I showed you how to use IP Security (IPSec) to protect sensitive information as it travels across your network. To guard the data, we first assigned the Client (Respond Only) IPSec policy in the Default Domain Policy Group Policy Object (GPO). Next, we created an organizational unit (OU) to contain all servers that host classified information. Then, we created a new GPO in that OU and assigned the Server (Require Security) IPSec policy to that GPO. Using a sniffer, I showed that this configuration does protect the data traveling to and from sensitive servers. However, creating a separate OU for the secure servers might not be an optimal solution in every environment.

For example, you might have already arranged your servers in OUs according to departments, regions, or server type. Pulling the servers out of their natural locations in your current OU hierarchy might disrupt the way in which you manage the configuration policy for GPOs that you've already linked to existing OUs. To compensate for this disruption, you would need to create redundant Group Policies in the classified server’s OU, which opens a can of worms from a maintenance standpoint. Fortunately, you have another option: You can use a GPO's ACL permissions to assign the Server (Require Security) IPSec policy.

To use GPO permissions to protect your classified information, you don't need to create any new OUs; you can leave the classified servers in place. Instead, start by creating a new GPO that links to the root of the domain and name it Classification Secret Computer Policies. Next, move the new GPO higher in relation to the Default Domain Policy using the Up button, as Figure 1 shows. Don’t edit the new GPO or assign any IPSec policy at this point; if you do, you’ll impact the IPSec policy of every computer in the domain. Instead, create a new security group called ClassificationSecretServers. So, instead of creating a group of user accounts, you're creating a group of computer accounts. Finally, add all the classified servers to this group, as Figure 2 shows.

Next, open the Properties window for the GPO you just created. Click the Security tab to see the GPO's ACL. This ACL controls which users can edit the GPO and which computers and users can apply it. To edit a GPO, you need Write access. For a computer to apply the Computer Configuration portion of a GPO to its local configuration, the computer must have both Read and Apply Group Policy access. By default, the Authenticated Users group has this access, which lets all users and computer apply a GPO. Delete the entry for Authenticated Users and replace it with one that allows Read and Apply Group Policy access to the ClassificationSecretServers group you just created, as Figure 3 shows. Now edit the GPO and assign the Server (Require Security) policy.

When another server (i.e., a server that doesn't host classified information) or workstation boots and applies Group Policy, it will encounter the Classification Secret Computer Policies GPO but it won't be able to apply it. Therefore, the server or workstation will fall back to using the IPSec policy according to the Default Domain Policy. Alternatively, when a classified server applies Group Policy, it will be able to apply the Classification Secret Computer Policies GPO by virtue of being a member of the ClassificationSecretServers group. Because the Classification Secret Computer Policies GPO is a higher priority than the Default Domain Policy GPO, as Figure 1 shows, the settings for the first policy will override the settings for the second policy wherever a conflict exists.

Filtering Group Policy application using GPO permissions is an effective way for handling those exceptions to Group Policy that don’t fit your typical OU hierarchy. However, I recommend that you use this method sparingly because GPO ACLs are partially hidden from normal view. As a result, you can easily miss the fact that a customized ACL might be limiting the application of a GPO. To help with this situation, it pays to be very descriptive with all GPO names, especially those GPOs with customized ACLs. Classification Secret Computer Policies specifies that this GPO is limited to settings under Computer Configuration (not User Configuration) and connected with classified data. You might also want to adopt a naming convention that flags GPOs with customized ACLs with a standard notation in the GPO’s name such as (ACL), as Figure 4 shows. This extra step will remind you and alert other administrators that application of this GPO is further filtered by its ACL.

As you can see, protecting sensitive information isn't difficult, even when it traverses the network, thanks to the integration between Group Policy and IPSec. However, you need to be careful with IPSec. If you've configured IPSec incorrectly, systems won't be able to negotiate security and network communications will fail. Be especially cautious when requiring IPSec on servers. Make sure that you've enabled all clients for IPSec that you want to connect to such a server. This caution particularly applies to widely accessed systems such as DHCP, DNS, WINS servers, and domain controllers.