Securing DC to DC communication with IPsec using Windows Firewall with Advanced Security (WFAS) Connection Security Rules

First published on TechNet on Dec 14, 2014

 

Hi folks, Lakshman Hariharan and Martin Solis here with a post on how to secure domain controller to domain controller communications using Windows Firewall with Advanced Security (WFAS) Connection Security Rules. Be forewarned that this is a long post, much of it taken up by screenshots.

 

A common example of an implementation is the securing of communications between domain controllers deployed in the perimeter network (DMZ) and the secure network. Firstly, why do we even need to secure communications between domain controllers using IPsec? One of the most common scenarios is when an organization deploys Read Only Domain Controllers (RODCs) in the DMZ segment of a network. This means that the domain controllers in the DMZ segment have to communicate with other domain controllers in the secure network segment(s), and therein lies our problem (if one were to call it that). Active Directory and DFS replication use a Remote Procedure Call (RPC) and RPC uses dynamic ports in the range of 49152-65535 in up-level (read Windows Server 2008 and above). Which means that to facilitate communications between the two domain controllers separated by firewalls a whole range of ports must be opened between these domain controllers by “swiss-cheesing” or poking metaphoric holes through the firewall.

 

Some firewalls are RPC aware and can dynamically open the required ports based on the different UUIDs being presented but many are not, and even with RPC aware firewalls many organizations’ network teams are understandably wary of doing so for reasons of network security and the cumbersome nature of maintaining such a setup.

 

Explanation of the concepts of RPC are beyond the scope of this post. Refer to this post for a good understanding of RPC concepts such as UUIDs, OpNums and such.

 

This is where using IPsec to encapsulate all communications between the domain controllers comes handy so instead of opening a whole range of ports only two UDP ports for ISAKMP (500 and 501) and one IP protocol for GRE (protocol 47) need to be allowed through the firewall.

 

Now that we have described why one may want to use IPsec to secure communications between domain controllers let’s move on to discussing the “how”. The rest of the post is intended as a step by step to walk through securing communications between two domain controllers using IPsec and optionally*, if desired encrypt such communications.

Following is the setup used for this demo that includes two domain controllers, one Windows client and one member server. The following table summarizes the roles, IP addresses and operating system running on these machines.

 

 

To perform this we will use six big steps sense that are further broken down into detailed individual steps. These six steps are:

 

1. Create a Group Policy Object

2. Create the Connection Security Rules

3. Create IPsec exclusions for DNS, ICMP and DHCP (optional) traffic since it is better to exclude name resolution, DHCP and ICMP traffic from IPsec.

4. Link the group policy object to the appropriate OU

5. Verify Communications are successfully secured.

6. Optionally encrypt the data being secured.*

 

Step 1: Create the group policy object

1. Logon to the domain controller and launch Group Policy Management Console (GPMC)

2. Create a new Group Policy Object (GPO) and name it DC to DC IPSec using WFAS

 

Step 2: Create the Connection Security Rules to Request Inbound and Outbound Security

1. Edit the GPO created in previous step by navigating to Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Windows Firewall With Advanced Security

 

2. Under Windows Firewall with Advanced Security select Connection Security Rules

3. Right click on Connection Security Rules and select New Rule

4. In the Rule Type screen select Server to Server and click Next

5. In the Endpoints screen select These IP Addresses under Which Computers are in Endpoint 1, select These IP Addresses and click Add

 

 

6. Under This IP address or subnet enter the IP addresses of the first domain controller and click OK

 

7. In the Endpoints screen select These IP Addresses under Which Computers are in Endpoint 2, select These IP Addresses and click Add.

8. Under This IP address or subnet enter the IP address of the second domain controller and click OK

Verify the IP addresses entered are accurate and click Next . Note that in any production scenario the Connection Security Rules created will most likely span subnets instead of individual IP addresses as demonstrated in this document. The subnets can be specified instead of actual IP addresses as described in the Examples of the screenshot above.

9. On the Requirements screen select Request authentication for inbound and outbound connections and click Next

10. On the Authentication Method screen select Computer certificate**, select the appropriate Certification Authority and click Next . Note that both endpoints must trust the same Certification Authority.

11. On the Profile screen select Domain, Private and Public and click Next

12. On the Name screen give the Connection Security Rule an appropriate name and click Finish

13. Locate the Connection Security Rule created in the previous steps, right click and click Copy and then Paste to make a copy of the rule, as shown in the following two screenshots.

14. Right click on one of the rules and click Properties and then select the Remote Computers tab

15. Select each of the IP address under Endpoint 1 and Endpoint 2 and click Edit

16. Reverse the IP address ranges or addresses as shown and click Ok, so connections initiated from either endpoint are secured via IPsec

 

Step 3 Create IPSec Exclusions for, DNS, ICMP and DHCP*** Traffic

1. Open Group Policy Management Console (GPMC), navigate to the policy created in Step 2, right click on it and Click Edit

2. Navigate to Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Windows Firewall With Advanced Security –> Connection Security Rules

3. Right click Connection Security Rules and click New Rule

4. On the Rule Type screen select Custom and click Next

5. On the Endpoints screen select These IP Addresses and enter the IP addresses for Endpoint 1 and Endpoint 2.

6. On the Requirements screen select Do not authenticate and click Next

7. On the Protocols and Ports screen Enter and/or select the following and click Next

Protocol Type: UDP

Endpoint 1 port: Specific Ports

Port number: 53

Endpoint 2 port: All Ports

8. On the Profile screen make sure Domain, Private and Public are selected under When does this rule apply? And click Next

9. On the Name screen type UDP 53 Exclusion for the Name and click Finish

10. Right click on the UDP 53 Exclusion rule created in the previous step and select Copy and then Paste as shown in the following three screenshots.

11. Right click on one of the two UDP 53 Exclusion rules, click on Properties and select the Remote Computers tab

12. Under Endpoint 1 and Endpoint 2 reverse the IP addresses for connections initiated from the other endpoint and click Ok

13. Repeat steps 1 through 9 to create an exemption for port TCP 53

14. Repeat steps 10 through 12 to clone the rule for TCP port 53 connections initiated from the other endpoint.

15. Repeat steps 1 through 9 to create an exclusion for ICMP. While creating the rule choose the following in the Protocols and Ports screen

16. If the domain controllers are running DHCP then create an exclusion for UDP ports 67 as outlined in steps 1 through 9.

 

 

Step 4 Link the Group Policy Object to the appropriate Organizational Units (OU)

1. Open Group Policy Management Console (GPMC), right click on the Domain Controllers OU and click Link and Existing GPO…

2. Select the GPO created in Step 2, in our case DC to DC IPSec using WFAS and click OK

 

3. Force group policy update on the domain controllers by executing the gpudate /force command

 

 

Step 5 Verify Communications are secure and successful

 

1. Capture a network trace when initiating communications between the two domain controllers whose communications have been secured using IPSec. This can be done several different ways. An easy way is to, say open the Event Viewer or the Services console and connect to the other domain controller. Or one could open a file share on the other domain controller from the first one.

2. Open the network trace in Microsoft Message Analyzer or Network Monitor 3.4. The screenshot below is using Network Monitor 3.4

3. Apply a display filter to only display traffic between the two domain controllers. In this case a display filter of ipv4.Address==10.0.0.2 has been applied, as seen in the screenshot below

4. Select any frame in the Frame Summary pane and observe the details in the Frame Details pane

5. Upon further inspecting each frame in the Frame Details pane one will observe that every frame has an additional ESP header indicating that the frame is encapsulated in ESP.

6. Spot check and inspect as many frames as possible to ensure that they contain the ESP header indicating that the data is encapsulated using ESP.

 

Step 6 (Optional) Encrypt Data Being Secured

 

1. Using Group Policy Management Console (GPMC), open the Group Policy Object created in the previuos steps and navigate to Computer Configuration –> Windows Settings –> Security Settings –> Windows Firewall with Advanced Security –>

2. Once at Windows Firewall With Advanced Security – LDAP://<Policy GUID>, DC=<domain name>, dc=<domain suffix>, right click on the policy and click on properties.

3. In the Properties window, click on the IPsec Settings tab

4. Click on the Customize button under IPsec defaults. This will bring up the Customize IPsec Defaults window.

5. Under Data Protection (Quick Mode), select Advanced and click on Customize. This will bring up the Customize Data Protection Settings as shown in the second screenshot.

6. Select the Require encryption for all connection security rules that use these settings checkbox.

7. Click OK three times.

 

 

Once group policy has refreshed on both domain controllers all communications will now be encrypted. Two screenshots of a network trace of encrypted communications are shown below. Note the frame details pane in the second screenshot where all the data is encrypted instead of only being encapsulated in ESP.

 

 

* There are two primary reasons where an organization may choose to secure but not encrypt the communications between domain controllers. The first being that in many organizations network teams may want to be able to still “sniff” the data using network monitoring tools and encryption renders such sniffing impossible. The second reason is performance. The encryption and subsequent decryption of data consumes additional CPU cycles on a server and adds to the load of what is in all likelihood an already busy domain controller.

 

**Note that the options available for authentication are Computer Certificate, Kerberos or Pre-shared key. We recommend using certificates because using Kerberos means another set of ports (UDP and TCP 88) having to be opened on the firewall(s). Plus using Kerberos for authentication has the potential of a "chicken and egg" scenario where IPsec depends on Kerberos but Kerberos issues could prevent IPsec. As for pre-shared key, because it is inherently insecure we recommend not using it for anything except for, say testing quickly a basic lab setup.

 

*** The DHCP exclusion is required only if the domain controllers are running DHCP. In this setup there are two domain controllers.

 

-Lakshman Hariharan and Martin Solis