Isolation Automation Exploration: Part II

In last
month's column we introduced the idea of isolation groups with Windows Vista.
These groups add an extra layer of authentication -- way down at the network
layer -- that forces a Kerberos computer authentication before checking any
user credentials. Adding in this extra authentication restricts highly sensitive
data communication to occur only among specific computers.

Using Vista's improved Windows Firewall with Advanced Security, it's much easier
than before to leverage IPSec and Kerberos authentication to create an isolation
group. Let's take a look at the steps necessary to implement a simplistic one
on your network.

The first step in creating an isolation group is to identify the workstations
and servers that will be in the group. That group can range from a few workstations
and a single server on up to every machine in your domain. In those cases where
only a single server is isolated, it can be used to ensure only certain workstations
can access data on that server. When an entire domain is isolated, all traffic
initiated from outside the domain can be blocked. This helps protect the domain
from external attack.

[Click on image for larger view.]

Figure 1. Workstations
in the isolation group are allowed to contact the payroll server. Workstations
outside the group and outside the domain are not..

In our example, we'll set up an isolation group between a payroll server, \\payrollsrv,
and two payroll workstations, \\payrollwks1 and \\payrollwks2. Once isolation
is established, only the two payroll workstations will be able to initiate a
connection to the server. All other network traffic initiated from other computers,
within or outside the domain, will be blocked by the isolation policy.

Note that the way we'll configure this policy will not affect the payroll server's
ability to initiate a connection to another computer. That would prevent it
from being a part of the domain or resolving other computers. Our policy will
only affect other computers' ability to initiate a connection to the payroll
server.

To set up the isolation group, open the Group Policy Management Console (GPMC)
on a Windows Vista machine and create a new GPO that is attached to the domain.
Isolation groups are supported on Windows Vista and Longhorn machines only,
so we need to create a GPO with a WMI filter that limits its application to
just those versions. The query we'll use for this WMI filter will be SELECT
* FROM Win32_OperatingSystem WHERE version >= '6'. You must ensure
that the GPO is linked to this WMI filter.

Next, we'll need to edit the GPO and configure the Connection Security Rules
for our isolation group. As before, this needs to be done on a Windows Vista
computer. Why? Because the options to configure the Windows Firewall with Advanced
Security are only available when the GPO is edited from within Windows Vista.

Choose to "Edit" the GPO and navigate to Computer Configuration |
Security Settings | Windows Settings | Windows Firewall with Advanced Security.
You'll immediately notice that the interface looks very similar to the one used
in Vista to configure local firewall rules. This makes the process very easy,
because if you've tested using local configurations then it's nearly the same
process to upgrade that local configuration to a Group Policy.

Then, you create a Connection Security Rule:

Right-click "Computer Connection Security" and select "New
Rule."

Select the type of Connection Security Rule. We discussed the types of
Rules in last month's column. For our example, so we can see all the possible
options, we'll choose to create a "Custom Rule."

In the next screen, we need to know the IP addresses of the computers at
both endpoints. Enter the address for the server into Endpoint 1 and the IP
address for the workstations into Endpoint 2.

Next, you're asked how you want the authentication to occur. In this example,
you want all inbound traffic to the payroll server to authenticate but you
don't want to require outbound traffic to do so. Doing this could prevent
the payroll server from interacting with other network resources like DNS
or Domain Controller services. So, in this step you'll choose to "Require
authentication for inbound connections and request authentication for outbound
connections."

The next screen allows you to select User, Computer or Computer Certificate
Authentication. You want to restrict access to specified computers, so we'll
choose "Computer Authentication."

You're then asked to limit the rule to Domain, Private or Public network
connection types. Because this authentication occurs within a Domain, you
need to choose only the "Domain" connection type.

Lastly, we give the Rule a name and finish the wizard.

The GPO is now configured, but because that GPO is currently attached to the
Domain, it now applies to all objects. You must limit its application to just
the payroll server and the two workstations. To do so, create a "Universal
Group" in Active Directory Users and Computers and add the three computer
accounts to that group. Then, in the GPMC, remove "Authenticated Users"
from the security-filtering box for the GPO and replace it with our Universal
Group.

Once Group Policy application is complete, the isolation group will be established
between the Vista workstations and the server.

Remember, this process works only if the workstations are Windows Vista and
the server is Windows Longhorn. Previous versions will not support Connection
Security Rules, and so must be configured using a local IPsec policy.

Previous versions also require the IPsec Simple Policy Hotfix (downloadable
here). After installing
the hotfix, create a registry entry at HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControl
Set\Services\PolicyAgent\Oakley\IKE Flags. Then, set the REG_DWORD value for
IKEFlags to 0x14.

Once the hotfix is installed, you'll use the local IP Security Policy Management
MMC console to create the policy on the Windows Server 2003 system. This can
be a complicated process. In the online version of this article, we'll provide
a simple netsh configuration file that can get you started.

More Information

Configuring Windows Server 2003 for Isolation -- The Old-Fashioned
WayConfiguring Vista for isolation is incredibly easy, but trying to
set it up in Windows Server 2003 can be a nightmare. A lot of this has to do
with the plethora of options exposed in the GUI.

In March, Microsoft released a document titled "Using Server Isolation
to Protect the Key Management Service (KMS)," which can be downloaded here.
This document discusses some of the very same configurations used in the article
above. But the document's example is used to enforce Vista computer authentication
against a KMS server prior to activating its license. This is needed in some
networks because activating against the KMS is by default open to any computer
with network connectivity to the KMS server.

Appendix A of this document details a sample server isolation IPsec policy
that can be used to jump-start the process of isolating a Windows Server 2003
computer. A variation of that sample policy is given below.

The text file above creates a new filter action called "Secure Request
Mode" that requires IPsec for inbound connections and sets that filter
action for all IP traffic inbound to the server. Unsecured communication with
non-IPsec-aware computers is allowed.

To use this sample configuration, copy the text above into a file and run the
command netsh -f {textfile.txt}. Once complete, you'll be able to view and modify
the configuration from within the IP Security Policy MMC console.

Although this example may not include all the exemptions and configurations
necessary for your network, it provides a basic starting point for setting up
isolation on a Windows Server 2003 computer. --G.S.

About the Author

Greg Shields is an Author Evangelist with www.PluralSight.com, and is a globally-recognized expert on systems management, virtualization, and cloud technologies. A multiple-year recipient of the Microsoft MVP, VMware vExpert, and Citrix CTP awards, Greg is a contributing editor for Redmond Magazine and Virtualization Review Magazine, and is a frequent speaker at IT conferences worldwide. Reach him on Twitter at @ConcentratdGreg.