Restricting AD Replication Traffic between DCs to only a few ports

Article
05/08/2012

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:

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.
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:

TCP/UDP 53 (DNS Name Resolution)
TCP/UDP 88 (Kerberos)
UDP 123 (Time Sync)
TCP 135 (RPC Endpoint Mapper)
TCP 49152 (AD REPLICATION. See Registry Key 1 below)
TCP 49153 (NETLOGON. See Registry Key 2 below)
TCP 49154 (FRS or DFS-R REPLICATION. See Registry Key 3 below)
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:

TCP/UDP 53 (DNS Name Resolution)
TCP/UDP 88 (Kerberos)
UDP 500 (IKE)
IP 50 (IPSec ESP)
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.

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

4. Do not check the box and click Next.

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

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…

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

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

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.

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

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.

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:

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:

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

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.

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.

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.

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”

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

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:

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.

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

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

Comments

Anonymous
January 21, 2013
With a Domain Infrastructure that has Windows 2003 and Windows 2008 Domain controllers, if I have to restrict the AD ReplicationLogon Ports, the range for Windows 2003 and Windows 2008 is different. So are we saying that the port will be different for Win2k3 and Win2k8. If yes, are we saying, we open it both the ports(hardcoded on Win2k3 and Win2k8)bi-directional on the Firewall. So, let's say if I already have a infrastructure with Windows 2003 DC's in a Firewall zone, that had the Replication traffic restricted over 3216. I then introduce a Windows 2008 domain controller. Since the Dynamic Port range for Windows 2008 Starts from 49152, I select 49155. So, with the above situation, do I need to start specifying two ports(3216 - 49152) over all the firewall rules.
Anonymous
July 29, 2014
Thank you for this post, very helpful. Do you happen know how the IPSec solution would be implemented on a Windows 2008 R2 CORE server with no GUI interface? I thought of exporting the IPSec rules from a server with a GUI, but do not trust that, since it's coming from another computer that could potentially have different config. A GPO that is filtered on an AD Group with the RODC's and RWDC's in it possibly. Also, another really important question: Do the RWDC's on the internal network need to be configured to talk to the rest of internal DC's? Essentially, do you need to configure all DC's in the environment to use IPSec for replication? Thanks again!
Anonymous
January 16, 2015
I am/was trying to open the specific firewall ports to install a new DC into an existing domain with a firewall in between.

I would highly recommend NOT using the ports recommended in this blog post at least as far as Windows Server 2012 R2 Domain Controllers go. In my case I set the AD Replication port to 49152 (as shown) and when the DC starts the RPC Endpoint Mapper handed out that port to the Windows Shutdown interface (UUID:d95afe70-a6d5-4259-822e-2c84da1ddb0d). If you run portquery against the DC you can see that port being given out to the Windows Shutdown Interface. AD Replication in turn ends up with 49155 in my case. I had already asked for the other port to be opened by the Security team. I think it would be best to get it right the first time. I would go as far to say that this blog needs to update those values to a higher number so some other person doesn't come along like myself and use those values, or at least make note of this. I would recommend moving all three to something higher. It appears the endpoint mapper hands out the dynamic addresses in numeric fashion so the higher the better.

My mistake was only checking to make sure that 49152 was listening using netstat -a | findstr 49152. I found it and assumed it was AD replication listening on that port. Using portquery GUI clearly shows the ports along with what they are being assigned to. Converting the UUID can be somewhat of a challenge though.

I would be interested to know if anyone else has experienced this issue.

Thanks,

Mike Niccum
Anonymous
June 22, 2015
The comment has been removed

Partager via