Restricting AD Replication Traffic between DCs to only a few ports

  • Artikel

 

Life is not perfect and sometimes the situation requires for you to put a firewall between Domain Controllers. I’m not here to discuss the reasons that require you to do so, but I must tell you that restricting AD DS traffic (firewall) is not something we recommend and used only when really necessary (avoided whenever possible). But once again, if there’s nothing you can do, let’s at least make sure all the vital traffic is indeed going through. I hope this guide is helpful to you!

 

clip_image001

There are at least two options that can be used to allow replication when there are network traffic filters (aka firewall) in the network, across two DCs. Both will be detailed here:

  1. Use registry keys on the DCs to force communication over specific ports (AD DS Replication, FRS Replication or DFS-R and Netlogon) and open a few extra ports for additional RPC communication.
  2. Use IPsec to restrict the traffic to two ports only (IP 50 and IP 51)

a. Full encryption (ESP) should be implemented, but you might want to consider using AH only (headers), so the traffic can be inspected if necessary (or required)

b. Kerberos can be used for authentication, but that requires port 88 (TCP/UDP) to be opened as well. You can use Certificates for the same purpose, which requires a CA installed, but keep you from opening an extra port in the firewall.

We’ll be assuming here that there’s no client traffic crossing the firewall, only AD replication. This means that if all of the DCs in either side fail, no authentication will be available at that side of the firewall, as the client traffic will be blocked across the firewall. If your scenario require authentication traffic to go thought the firewall, additional ports might be needed.

Please notice that if you’re restricting DC replication through a firewall because one of your DCs is in a perimeter (DMZ) network, consider deploying RODCs to achieve a higher security level. Check the following guide for more information about Deploying RODCs in the Perimeter Network: https://technet.microsoft.com/en-us/library/dd728035.aspx

Restricting DC traffic using registry keys

Configure your firewall to allow the following ports:

  1. TCP/UDP 53 (DNS Name Resolution)
  2. TCP/UDP 88 (Kerberos)
  3. UDP 123 (Time Sync)
  4. TCP 135 (RPC Endpoint Mapper)
  5. TCP 49152 (AD REPLICATION. See Registry Key 1 below)
  6. TCP 49153 (NETLOGON. See Registry Key 2 below)
  7. TCP 49154 (FRS or DFS-R REPLICATION. See Registry Key 3 below)
  8. TCP 5722 (DFS-R Replication)

Then set the following registry keys on your Domain Controllers. Once you’re done, reboot the DCs for the settings to take effect. In theory, since the KCC controls the replication topology and not you, you should apply these changes on all your DCs, in case they ever need to replicate with each other. However, for security reasons, you can just configure it on the DCs facing both sides of the firewall:

Registry key 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Registry value: TCP/IP Port
Value type: REG_DWORD
Value data: 49152 (This value needs to be specified in decimal format)

Registry key 2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registry value: DCTcpipPort
Value type: REG_DWORD
Value data: 49153 (This value needs to be specified in decimal format)

Registry key 3
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters
Registry value: RPC TCP/IP Port Assignment
Value type: REG_DWORD
Value data: 49154 (This value needs to be specified in decimal format)

If you’re using DFS-R, you want to run the following command instead:
dfsrdiag StaticRPC /port:49154 /Member: <serverFQDN>

References:
Restricting Active Directory replication traffic and client RPC traffic to a specific port
https://support.microsoft.com/kb/224196

How to configure RPC dynamic port allocation to work with firewalls
https://support.microsoft.com/kb/154596

How to restrict FRS replication traffic to a specific static port|
https://support.microsoft.com/kb/319553

Service overview and network port requirements for the Windows Server system
https://support.microsoft.com/kb/832017

Restricting DC traffic using IPSec

IPSec provides a way to easily encapsulate and carry traffic over a firewall. IPSec can also increase security between the DCs using mutual authentication (Kerberos or machine certificates). That way, DCs can guarantee to whom they are communicating with before any actual information exchange occurs.

However, there’s a key decision that must be made at this point - whether to use Certificates or Kerberos for IPSec Authentication. If using Kerberos, you won’t be able to perform the DCPROMO behind the firewall, as the computers must be a member of the domain. If instead you want to use certificates, you need a CA (AD CS) to obtain a certificate for each DC.

For IPSec replication, configure your firewall to permit the following:

  1. TCP/UDP 53 (DNS Name Resolution)
  2. TCP/UDP 88 (Kerberos)
  3. UDP 500 (IKE)
  4. IP 50 (IPSec ESP)
  5. IP 51 (IPSec AH)

Note that IPSec will not work through network address translation (NAT) devices. Because IPSec uses IP addresses when computing packet checksums, IPSec packets whose source addresses were altered by NAT are discarded when they arrive at the destination.

So let’s move on and start configuring the DCs. In our example scenario here, there are 3 DCs running Windows Server 2008 R2, but you can run a mix of 2003, 2008 and 2008 R2, as the configuration is pretty much the same. Two DCs are inside the corporate network (DC1 and DC2) and one DC is outside the perimeter (DC4).

We’re going to configure the IPSec policy on all 3 DCs, so they use IPSec transport mode to communicate with each other. Note that we are not creating IPSec tunnels, but using IPSec transport mode - end-to-end IPSec – instead.

Configuring the Servers

NOTE: To make this setup easier, I promoted all DCs in the same network (no firewalls) and tested replication to make sure no problems existed before continuing with the IPSec policy creation.

Starting with DC1, run the following steps to create an IPSec policy for replication, along with a corresponding IP filter list and filter action.

1. Open Start | Administrative Tools | Local Security Policy.

clip_image003

2. Right-click IP Security Policies on Local Machine (in the left-hand pane of the MMC) and select Create IP Security Policy.

3. Click Next and provide your IPSec Policy with a name

clip_image005

4. Do not check the box and click Next.

clip_image007

5. Now make sure “Edit Properties” is checked and click Finish.

clip_image009

6. Now at the IPSec Policy Properties (DC Replication), you can see no rules are in effect. You want to create a new rule, so click Add…

clip_image011

7. Click Next and make sure “This rule does not specify a tunnel” is selected. Click Next.

clip_image013

8. Select “Local Area Network (LAN)” and click Next again.

clip_image015

9. In the IP Filter List screen, click Add…

10. The IP Filter List window will open. Click Add and follow the wizard to create three filters, from <My IP Address> to all other DCs that will participate in this communication, including DC1 itself. This will make sure all traffic from all DCs is forced to use IPSec. In this example, we have three filters, from DC1 to DC1, DC2 and DC4. Make sure the Mirror check box is selected, and the filter includes all Ports and Protocols. Click OK when done.

clip_image016

11. Back to the IP Filter List Screen, select the newly created filter and hit next.

clip_image018

12. Now we need to create a Filter Action. In the Filter Action screen, click Add…

13. Name the filter DC Replication Action

14. Select “Negotiate Security” and click Next

15. Make sure you select “Do not allow unsecured communication” and click Next

16. And now to the first important choice: the security implemented with IPSec.

clip_image020

a. In the screen shown above, if you select “Integrity and encryption”, ESP will be in effect, using Protocol IP50. It means all packages matching the filter list will be encrypted and then a checksum generated to protect against tampering. By default SHA1 is used for Integrity and 3DES for Encryption, as you can see below:

clip_image022

b. Some companies’ security departments require the ability to inspect network packages, and if that’s your case, you probably don’t want to encrypt the payload, but only enforce only Data and Address integrity (header checksum). In this case, select the Custom… option and use the following options:

clip_image024

17. Back to the Filter Action Screen, select the newly created Action and hit next.

clip_image026

18. Now it’s time for the second decision! Are you going with Kerberos Authentication or Certificates? In this example, we’ll use Kerberos, as all Domain Controllers are already operational, and Kerberos is available. So click Next.

a. Please check https://technet.microsoft.com/en-us/library/bb742429.aspx#EEAA for instructions on how to configure a CA (AD CS) and obtain a computer certificate for IPSec Authentication.

b. If using certificates, you also might want to check the following document https://social.technet.microsoft.com/wiki/contents/articles/584.active-directory-replication-over-firewalls.aspx#DCPromoIPSec to understand how to force Kerberos packets to be encapsulated by IPSec.

clip_image028

19. Click Finish.

20. You will be taken to the IPSec Policy Properties again, where the DC Replication Rule is already selected. Just click OK to confirm.

clip_image030

21. Finally, you need to turn on (or assign) the policy to the DC. So back to the Local Security Settings Window, right-click the DC Replication policy and select Assign.

clip_image032

22. IPSec processing happens immediately. There is no need to reboot the server.

Now that we are done with DC1, since every domain controller requires a similar IPSec policy, it is necessary to repeat all above steps for the remaining DCs. Regardless of whether the controller is in the internal network, the perimeter network, or the external network, you must configure its IPSec policy so that all communications with all other domain controllers are through IPSec. Not only does this allow the knowledge consistency checker to build a replication topology that ignores the firewall, it also secures all IPSec replication between every server.

Testing the IPSec Policy

Once you’re done with configuring all servers, we want to make sure replication is taking place and no important packets are being dropped by the firewall. In this scenario, I’ve used Hyper-V as the virtualization platform, and an extra computer running Forefront TMG to act as the firewall. I’ve also installed NETMON 3.4 to make sure packets could be inspected if using AH only.

1. From DC1, open AD Sites and Services (dssite.msc), expand the site that contain your DCs and find DC1.

2. Expand NTDS Settings and select all Replication Connection objects on the right-hand side panel.

3. Right click the Connection Objects and select “Replicate Now”

clip_image034

4. You should get the following message, indicating replication is working

clip_image036

5. Repeat that for all DCs, so you force a full replication cycle. You can also open a cmd window and type “repadmin /replsum /bydest”, which should give up an output similar to the screen shown below:

clip_image038

6. You can also create a file on SYSVOL (C:\Windows\Sysvol\domain) and see if it replicates to all other DCs. This tests the FRS Replication.

7. From a NetMon 3.4 window you can see the traffic going through as we’re using AH only in this example.

clip_image040

8. You can also notice no packet drops in the firewall

clip_image042

References:
IKE: Internet Key Exchange
ESP: Encapsulated Security Payload
AH: Authenticated Header

Active Directory Replication Over Firewalls
https://social.technet.microsoft.com/wiki/contents/articles/584.active-directory-replication-over-firewalls.aspx

How to Enable IPSec Traffic Through a Firewall
https://support.microsoft.com/kb/233256

Step-by-Step Guide to Internet Protocol Security (IPSec)
https://technet.microsoft.com/en-us/library/bb742429.aspx