You’ve probably faced this situation at one time or another—users want unrestricted access to the network and the Internet while at the same time you need to maintain a high level of security. To meet these often conflicting demands, you can use domain isolation and IPsec to create isolated networks that are secure, without having to make expensive hardware or software changes.
To use domain isolation on Windows Server 2003, make sure you’re familiar with IPsec. For an introduction to IPsec, see “Use IPsec to Encrypt Data” (http://www.securityprovip.com/Articles/ArticleID/96508/96508.html). Before we talk about how to configure domain isolation, let’s look at the myths of domain isolation and some of its limitations. Then we’ll examine a simple scenario in which we use Group Policy to push out a simple IPsec policy to enable domain isolation.
What Is Domain Isolation?
Domain isolation is the ability to protect a group of computers—for instance, those that belong to a Windows Active Directory (AD) domain—from those that don’t have domain membership. An example of how domain isolation might be useful is when a visitor to your office plugs a laptop into a network port for Internet access or some other reason. No matter how diligent you are at ensuring your patches and antivirus definitions are up-to-date, your efforts might be in vain if an infected machine were to connect to your network. IPsec domain isolation creates a barrier to protect the domain at the network layer, which means traffic can transparently traverse routers, switches, and hubs. One advantage of IPsec over the Windows Firewall in Windows XP is that IPsec can provide outbound as well as inbound filtering.
Myths of Domain Isolation
As with IPsec, several myths surround domain isolation, restricting its adoption in the real world. Many administrators mistakenly believe that implementing domain isolation means having to encrypt all network traffic. The extra complexity that encryption brings and the inability to troubleshoot the network using traditional monitoring tools when traffic is encrypted don't seem worth the extra protection. Let’s look at some of the myths surrounding IPsec and domain isolation:
Myth 1: Domain isolation and IPsec require a certificate server. Public key infrastructure (PKI) certificates can be used in conjunction with IPsec, and PKI is the preferred method in some scenarios, but for the purposes of domain isolation in a single AD domain or forest, Kerberos V5 (which is available as part of AD by default) can be used.
Myth 2: Domain isolation requires that all traffic be encrypted. IPsec can provide authentication, or authentication and encryption. Encryption is optional and isn’t a requirement for domain isolation.
Myth 3: Domain isolation and IPsec make it impossible to use packet sniffers. If you choose not to encrypt traffic using IPsec, most traditional network monitoring tools (including Microsoft’s own Network Monitor) can sniff IPsec authentication header (AH) traffic. So the ability to use packet sniffers depends on how you configure IPsec for domain isolation.
Myth 4: IPsec is the only way of implementing domain isolation. 802.1x is a standard for passing Extensible Authentication Protocol (EAP) over a LAN or wireless network and provides authentication only, with no support for data integrity. 802.1x is most commonly used to help secure WLANs. It’s less scalable than IPsec and requires that all hardware specifically support it. For these reasons, 802.1x doesn’t provide the same complete solution that IPsec offers.
Some Important Limitations of Domain Isolation
Before you implement domain isolation on your network, you should be aware that domain isolation has a few limitations that might affect your decision to use it.
Infrastructure servers (such as domain controllers—DCs—and DHCP servers) can’t be included in an isolation domain. Before an IPsec security association (SA) can be negotiated, a client machine must be authenticated with a DC to be issued a Kerberos ticket. It is possible to include infrastructure servers in isolation domains by using complex rules or shared secrets, but these workarounds are not ideal. Windows Server 2008 will offer a simplified IPsec policy configuration to help address this problem. It’s also possible to download the Simple Policy Update for Windows XP and Windows Server 2003. See the Microsoft article "How to simplify the creation and maintenance of Internet Protocol (IPsec) security filters in Windows Server 2003 and Windows XP" (http://support.microsoft.com/default.aspx/kb/914841/en-us) for more information about the Simple Policy Update.
Domain isolation in its most basic form doesn’t prevent infected clients within the isolation domain from attacking one another. However, more complex IPsec configurations could be used to create further defenses within the isolation domain itself.
Legacy clients such as Windows 98 don’t support policy-based IPsec and therefore can’t participate in an isolation domain. Windows 98 can, however, support IPsec for the purposes of creating VPN connections.
Configuring Domain Isolation
Let’s consider a scenario with a single Windows 2003 AD domain and/or forest and no legacy clients or servers (i.e., nothing earlier than Windows XP SP2 and Windows 2000 SP4) for which we want to implement domain isolation without encrypting the traffic. No devices outside the domain need to communicate with devices placed inside the barrier created by domain isolation. We’ll also assume that all machines are hosted on one subnet and that infrastructure services such as DNS and DHCP are hosted by a single DC.
We’ll use Group Policy to push out an IPsec policy to servers and clients in the domain. In this simple scenario, a single IPsec policy is all that’s required to enable domain isolation. In more complex situations, more than one IPsec policy might be required.
Step 1: Create a new OU and Group Policy Object (GPO). Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in from Administrative Tools in the Control Panel. Right-click the domain node (e.g., mydomain.com), and select New, Organizational Unit. Call it Isolation Domain, and press OK. Drag and drop any computer accounts (but not infrastructure servers such as DCs and DHCP servers) that you want to include in the isolation domain to the new organizational unit (OU) and then close the Active Directory Users and Computers snap-in.
Open Group Policy Management Console (GPMC) from Administrative Tools. Right-click Group Policy Objects, select New, name the policy Domain Isolation, and click OK.
Expand the Group Policy Objects node. Right-click the new Domain Isolation policy, and select Edit. The Group Policy Object Editor window will open.
Step 2: Create the domain isolation IPsec security policy. Expand Computer Configuration, Windows Settings, Security Settings. You’ll see IPsec security policies on Active Directory at the bottom of the list. Right-click it and select Create IPsec Security Policy.
Click Next past the introduction; on the next screen, give the IPsec policy the name Domain Isolation. Clear the Activate Default Response Rule check box, and click Next. Ensure that Edit Properties is selected, and click Finish.
Now to create a rule, click Add on the Rules tab, and click Next past the introduction screen. We’re using transport mode, so click Next on the Tunnel Endpoint screen. On the Network Type screen, let’s include all connections, and click Next.
Step 3: Create a DC filter list and an isolation domain filter list. Now we need to create two filter lists. We need one to ensure that DCs are excluded from the isolation domain and another to define the isolation domain subnet.
To create a DC filter list, click Add, and give the new filter list a name: Domain Controller. Click Add to start the IP Filter Wizard, and click Next past the introduction screen. Enter a description such as Exclude domain controllers from the isolation domain. Ensure that the Mirrored box is checked and click Next.
On the source address drop-down menu, select My IP Address and click Next. For the destination IP address, select A specific IP Address, and enter the IP address of your DC. Click Next.
On the IP Protocol Type screen, leave the default selection of Any, and click Next. Clear the Edit Properties check box, and click Finish. Click OK to return to the Security Rule Wizard. You’ll now see the new Domain Controller filter list appear below the existing All IP Traffic and All ICMP Traffic filter lists.
Now let’s add a second filter list. To create an isolation domain filter list, click Add, and call the new filter Isolation Domain. Click Add to start the IP Filter Wizard, and click Next past the introduction screen. Give the filter a description, ensure that the Mirrored box is checked, and click Next. On the source address drop-down menu, select My IP Address and click Next.
For the destination IP address, select A specific IP Subnet, and enter the IP address range and subnet mask for the network segment. Click Next.
On the IP Protocol Type screen, leave the default selection of Any, and click Next. Clear the Edit Properties check box and click Finish. Click OK to return to the Security Rule Wizard.
For the time being, we can select only one of the filter lists. Select Isolation Domain as Figure 1 shows, and click next.
Step 4: Create a new filter action. On the Filter Action screen, select Add and click Next past the Welcome screen. Give the new filter action the name Isolate Domain and a description, and click Next.
Leave the default selection of Negotiate Security and click Next.
Select Fall back to unsecured communication and click Next. I explain exactly what this means in the next section on soft SAs.
Select Integrity only; click Next and then Finish.
Back at the Security Rule Wizard, you’ll now see the new filter action listed along with the three default actions. Select the Isolate Domain filter action and click Next.
Step 5: Complete the Isolation Domain rule. On the Authentication Method screen, leave the default Active Directory default (Kerberos V5 protocol) option selected, and click Next. Clear the Edit properties check box on the completion screen and click Finish.
Back at the screen where we started (the properties dialog box for the new domain isolation IPsec policy) we see the new Isolation Domain rule selected above the Default Response rule, which is switched off.
Step 6: Create a rule to exclude DCs from the isolation domain. We need to add two more rules to complete the configuration. Let’s click Add at the bottom of the properties dialog box for the domain isolation policy.
Click Next past the introduction screen. Leave the default selection and click Next on the Tunnel Endpoint screen. On the Network Type screen, let’s include all connections and click Next.
Select Domain Controller from the list of IP filters and click Next. Under Filter Actions, select Permit; click Next, then Finish.
Step 7: Create a rule to allow Internet Control Message Protocol (ICMP) traffic. This rule allows ICMP traffic to flow within the isolation domain but not into it when initiated from untrusted sources.
Click Add in the Domain Isolation properties dialog box, then click Next past the introduction screen. Again, leave the default selection and click Next on the Tunnel Endpoint screen. On the Network Type screen, let’s include all connections and click Next.
Select All ICMP Traffic from the list of IP filters and click Next. Under Filter Actions, select Permit; click Next and then Finish. The resulting Domain Isolation properties dialog box shows the three new rules activated, as you can see in Figure 2. Click OK to complete the configuration.
Step 8: Assign the new policy. In Group Policy Object Editor, click IP Security Policies for Active Directory, and you’ll see the domain isolation policy we just created. The policy is not assigned by default. Right-click the policy, and select Assign. Its status should change in the window.
Close Group Policy Object Editor and go back to GPMC. We now need to link the GPO to the Isolation Domain OU. Right-click the Isolation Domain OU in GPMC and select Link an Existing GPO. Select the domain isolation policy from the list and click OK. You’ll now see the domain isolation policy linked under the Isolation Domain OU, as Figure 3 shows. On a machine in the Isolation Domain OU, run the following commands to update Group Policy and ensure the IPsec policy is applied:
gpupdate /force net stop policyagent net start policyagent
Repeat this on any other machines in the Isolation Domain OU that you want to include in testing.
Soft SAs
When we were configuring the isolate domain filter action, we selected an option called Fall back to unsecured communication. Microsoft’s documentation refers to this functionality using various terms: Fall back to clear; Allow unsecured communication with non–IPsec-aware computers; Negotiate soft security associations.
When the Fall back to clear option is selected, outbound communication to untrusted devices from within the isolation domain will be secured only if the target supports IPsec and has a corresponding filter action. If not, communications will be unsecured and two-way. This soft SA will remain open for five minutes after traffic stops flowing. After this time, a machine within the isolation domain has to reinitiate a link with the untrusted machine before unsecured data can pass between them again. Fall back to clear doesn’t have to be configured for domain isolation to work, but it’s an option if you need flexibility when communicating with untrusted devices.
Testing
Initiate some form of communication between hosts inside the isolation domain and use the IPsec monitor tool as described in "Use IPsec to Encrypt Data" to see whether SAs are being established successfully. You should be able to freely communicate between all hosts inside the domain.
Try pinging the DC from an untrusted device (i.e., a device outside the isolation domain). You should get a reply. Try pinging a trusted host (i.e., a device inside the isolation domain) from the untrusted device, and you should get a Request timed out response.
Ping an untrusted device from a trusted host. You should get a reply because of the Fall back to clear configuration in the IPsec policy. Note that you might have to issue the ping command twice to get a reply because it takes a few seconds to negotiate an SA. If you then ping from the untrusted device to the trusted host where you initiated the original ping, you should also get a reply. Repeat the ping five minutes later and you should get a Request timed out response.
A Valuable Defensive Layer
Domain isolation can provide a valuable layer of defense against untrusted devices that might find their way on to your network. (For more information about domain isolation, read the Microsoft article “Server and Domain Isolation” at http://www.microsoft.com/sdisolation.) Domain isolation in its simplest configuration needn’t introduce too much additional complexity to your network. If you’re confident working with IPsec, more complex configurations can provide extra protection.