Overview of the Windows Server 2008 Firewall with Advanced Security Part 3a: Introduction to Domain Isolation

by [Published on 8 July 2008 / Last Updated on 8 July 2008]

How to use Group Policy to enforce domain isolation through the use of IPsec.

If you would like to read the other parts in this article series please go to:

If you would like to be notified when Thomas Shinder releases the next part of this article series please sign up to the WindowSecurity.com Real time article update newsletter.

In the first two parts of this series on the Windows Firewall with Advanced Security, I went over the general configuration options for the Windows Firewall and then discussed details of inbound and outbound firewall rules.

In this, the third article in the series, we will take a look at how to use Group Policy to enforce domain isolation through the use of IPsec. The Windows Firewall with Advanced Security console is integrated with Windows Server 2008 Group Policy, thus allowing you to use the Group Policy Management console and the Group Policy Editor to create Firewall policy for machines in the entire domain, in an OU, or on a site.

Domain Isolation configuration (through the Windows Firewall with Advanced Security interface) allows you to protect all of your domain member machines from rogue machines that are not domain members. Domain members are configured so that they must authenticate with one another before connections are allowed between them. Machines that are not domain members cannot authenticate to domain members, and thus connections from non-domain members fail.

While this was possible to do in previous versions of Windows, the configuration interface for configuring IPsec policies was so complex, and so difficult to understand, that not many Windows or security admins bothered with domain isolation. However, with the introduction of the Windows Firewall with Advanced Security in Windows Server 2008 and Vista, it is very easy to get a working domain isolation configuration. And it’s integration with Windows Server 2008 Group Policy allows you to easily centralize the configuration so that you have a “one-touch” solution.

In this two part series (Part 3 is split into 2 separate parts) on domain isolation I am going to demonstrate how you can create a domain isolation solution for a simple three machine network. These machines are:

  • A domain controller that will request security. You cannot force security because machines apparently are not able to receive group policy when you force security. However, if you request security when connecting to the domain controller, the domain members are able to connect to the domain controller to get group policy and then they are able to secure the rest of their communications with the domain controller. IP address in this example will be 10.0.0.2
  • A server that requires security. This could be any kind of server – file server, database server, Web server. When we demonstrate the connections at the end of the article, we’re just going to enable pings to the server to see that the connection security rules work. IP address in this example will be 10.0.0.3
  • A Windows Vista client. This machine will connect to the server and the domain controller. IP address in this example is 10.0.0.100

The servers are Windows Server 2008 machines, and all three machines are part of the same domain.

You do not need to install any special roles or role services or features to get domain isolation to work.

Note that this is a very simple scenario and does not include the exceptions that you need to make for infrastructure servers on your network, such as DNS, DHCP or WINS servers and also for the default gateway.

It is important on a production network that you create these exceptions to IPsec policy enforcement so that machines that are not domain members can still communicate with these infrastructure servers. I will include a link at the end of this article series that you can use to get more information about planning for a domain isolation scenario for your production network.

Configuring the Default IPsec Policy to Require Encryption

In the example we are using in this article, we want to make sure that IPsec is used not only to control what computers can connect to one another, but also to make sure that no one can sniff private information that’s shared between domain member computers. In order to do that, we can use ESP encryption.

In order to get ESP encryption to be part of the default IPsec settings, we need to get into the Properties of the Windows Firewall with Advanced Security in the Group Policy Editor.

Open the Group Policy Management Console on your domain controller and then open the Default Domain Policy for your domain (or test domain if you’re doing this in a test environment) in the Group Policy Editor.

In the left pane of the Group Policy Editor, expand a number of nodes as seen in the figure below. The path is:

Computer Configuration\Policies\Windows Settings\Windows Firewall with Advanced Security

Right click on that node and click the Properties command.


Figure 1

In the Windows Firewall with Advanced Security dialog box, click on the IPsec Settings tab. On the IPsec Settings tab, click on the Customize button.


Figure 2

In the Customize IPsec Settings dialog box, select the Advanced option in the Data protection (Quick Mode) frame. Click the Customize button.


Figure 3

In the Customize Data Protection Settings dialog box, put a checkmark in the Require encryption for all connection security rules that use these settings checkbox. Notice that AES-128 will be used by default, but if the client/server combination doesn’t support this level of encryption, then they will fall back to 3DES (triple DES). Click OK.


Figure 4

Now that we’ve configured the default IPsec settings to support encryption of connections between the isolated hosts, we can get to the job of creating the Connection Security Rules.

Creating the Domain Controller Request Security Rule

One thing I noticed in my research and testing for domain isolation using IPsec was a big problem related to domain controllers. Whenever I configured the IPsec policies to require security to the DC, the connections from the domain members would fail and the domain members were never able to reach the log on screen. However, if you configure the IPsec rules to request security, then domain members were able to log on and connect to the domain controller. In addition, when request security was configured, the clients were able to establish secure IPsec connections to the domain controller after receiving Group Policy over what I assume is a unsecure connection.

I don’t know why you can’t require security when configuring IPsec policies for domain controllers, but I do know that if you require security, instead of requesting security with a domain controller, you’re going to have a very bad day.

However, we can request security when connecting to the domain controllers. This will allow us to establish a secure connection to the domain controller, even though we are not requiring security on the connection.

In the Group Policy Editor navigate to the Connection Security Rules node in the left pane of the console under the Windows Firewall Advanced Security Node, as seen in the figure below. The complete path to this node is:

Computer Configuration\Policies\Windows Settings\Windows Firewall with Advanced Security\Connect Security Rules

Right click on the Connection Security Rules node and click New Rule.


Figure 5

On the Rule Type page in the New Connection Security Rule Wizard, select the Isolation option and click Next.


Figure 6

On the Requirements page, select the Request authentication for inbound and outbound connections. When you select this option, authentication is requested when the computer makes an outbound connection to another computer, and when another computer makes an inbound connection to this computer. If authentication succeeds, then IPsec security is applied to the sessions. However, if authentication fails, the machines will fall back to unauthenticated connections.

Click Next.


Figure 7

On the Authentication Method page, select the Default option. The Default option is determined by the settings in the IPsec Defaults from in the Properties of the Windows Firewall with Advanced Security dialog box that we saw earlier. We also went through the details of that dialog box in the first part of this article series on the Windows Firewall with Advanced Security, so you should check that out for details on IPsec policy defaults.

The default settings will use Kerberos for authentication. Since all domain members can use Kerberos of authentication, there’s nothing you need to do on the clients and servers. There are a number of ways to authenticate, such as Computer Certificate or pre-shared key. But the most secure method is Kerberos and given that there isn’t any administrative overhead to use Kerberos, that’s clearly the best way to go.

Click Next.


Figure 8

On the Profile page, remove the checkmarks from the Private and Public checkboxes. You don’t want your mobile computers to have to worry about IPsec domain isolation when they’re off the network.

Click Next.


Figure 9

On the Name page, give the rule a name. In this example we’ll name the rule DC Request Security. Click Finish.


Figure 10

You will see the rule in the list of rules as seen in the figure below. We’re not yet done with the rule, as we need to configure the IP addresses that this applies too. You can see in the line that currently, the rule applies to any Endpoint 1 and any Endpoint 2. The endpoints can be one IP and another IP address, or one endpoint can be a group of IP addresses and the second endpoint can be a single IP address.

In this example we need to create one endpoint to be all IP addresses on the network and the second endpoint to be the IP address of the domain controller used in this example.

Right click on the DC Request Security Rule and click Properties to make these changes.


Figure 11

On the DC Request Security Properties dialog box, select the These IP addresses option in the Endpoint 2 frame. Then click the Add button.


Figure 12

In the IP address dialog box, put the IP address of your domain controller. Select the This IP address or subnet option and enter the IP address. Notice that you also have the This IP address range and the Predefined set of computers options. The Predefined set of computers option allows you to select from a number of infrastructure servers, such as DHCP, DNS, WINS and default gateway, so that machines that can’t authenticate can be exempted from authenticating with these infrastructure servers. Examples would be Macs, Unix, Linux and other operating systems that can use Microsoft Kerberos to authenticate.

Click OK.


Figure 13

Should now see the IP address of the DC in the Endpoint 2 frame. Click OK in the DC Request Security Properties dialog box.


Figure 14

You should now see the IP address of the domain controller in the Endpoint 2 column on the DC Request Security line.


Figure 15

Now that the DC request security policy is in place, we can create the client and server domain isolation rule that will require security when connecting to other domain members.

Summary

In this, the first part of a two part series on how to create a domain isolation policy using the Windows Firewall with Advanced Security interface integrated into the Windows Group Policy Editor, we configured the default IPsec policy to force ESP encryption. Then we created a domain controllers IPsec policy rule and modified it by setting the Endpoint 2 to be the IP address of the domain controller.

In the second part of this series, we will create the client and server domain isolation rule and then configure the server to accept Ping requests. See you then! –Tom.

If you would like to read the other parts in this article series please go to:

If you would like to be notified when Thomas Shinder releases the next part of this article series please sign up to the WindowSecurity.com Real time article update newsletter.

See Also