Microsoft's official enterprise support blog for AD DS and more
Hi, Dave here. I’m a Support Escalation Engineer in Directory Services out of Charlotte, NC. Recently one of our consultants in the field deployed a Windows Server 2008 Beta 3 domain controller at a branch office to test management scenarios. After doing this, they discovered that the server was not replicating with domain controllers at the main datacenter. After running some network captures, they discovered that the local firewall was blocking replication traffic.
The firewall in question was configured properly to allow Windows Server 2003 domain controllers to replicate, but the Win2008 domain controller was blocked. This is not because we changed the way replication works per se. Replication is still accomplished by server to server RPC calls, the same as in Win2003. But we did change the underlying mechanism that the network stack uses to determine which ports those RPC calls use.
By default, the dynamic port range in Windows Server 2003 was 1024-5000 for both TCP and UDP.
In Windows Server 2008 (and Windows Vista), the dynamic port range is 49152-65535, for both TCP and UDP.
What this means is that any server-to-server RPC traffic (including AD replication traffic) is suddenly using an entirely new port range over the wire. We made this change in order to comply with IANA recommendations about port usage. Therefore, if you start deploying Windows Server 2008 on your network, and are using firewalls to restrict traffic on your internal network you will need to update the configuration of those firewalls to compensate for the new port range.
It doesn’t stop at RPC traffic though. The dynamic port range is used for any and all outbound requests from your computer that don’t use a specific source port. This means that if you fire up Internet Explorer and browse to a web page, the network traffic is going to source from a port higher than 49152 on Vista or 2008. This means that potentially, any application that connects to other machines via the network could be impacted by a firewall that’s not configured for this change. In Directory Services support here at Microsoft, we really care mostly about Active Directory related traffic, but this is something that everyone should watch out for. So for example, look at this snippet of a NETSTAT command run on a Vista machine where we are simply connected to a web site with IE7:
C:\Windows\system32>netstat -bnActive ConnectionsProto Local Address Foreign Address StateTCP 10.10.0.10:53556 220.127.116.11:80 TIME_WAITTCP 10.10.0.10:53572 18.104.22.168:80 TIME_WAIT[iexplore.exe]
In Vista and 2008, most administration of things at the network stack level is handled via NETSH. Using NETSH, it’s possible to see what your dynamic port range is set to on a per server basis:
>netsh int ipv4 show dynamicport tcp>netsh int ipv4 show dynamicport udp>netsh int ipv6 show dynamicport tcp>netsh int ipv6 show dynamicport udp
These commands will output the dynamic port range currently in use. Kind of a neat fact is that you can have different ranges for TCP and UDP, or for IPv4 and IPv6, although they all start off the same.
In Windows Server 2003 the range always defaults to starting with TCP port 1024, and that is hard-coded. But in Vista/2008, you can move the starting point of the range around. So if you needed to, you could tell your servers to use ports 5000 through 15000 for dynamic port allocations, or any contiguous range of ports you wanted. To do this, you use NETSH again:
>netsh int ipv4 set dynamicport tcp start=10000 num=1000 >netsh int ipv4 set dynamicport udp start=10000 num=1000 >netsh int ipv6 set dynamicport tcp start=10000 num=1000 >netsh int ipv4 set dynamicport udp start=10000 num=1000
The examples above would set your dynamic port range to start at port 10000 and go through port 11000 (1000 ports).
A few important things to know about the port range:
· The smallest range of ports you can set is 255.· The lowest starting port that you can set is 1025.· The highest end port (based on the range you set) cannot exceed 65535.
For more information on this, check out KB 929851.
At this point you’re probably wondering what our recommendation is for configuring firewalls for AD replication with Windows Server 2008. Generally speaking, we don’t recommend that you restrict traffic between servers on your internal network. If you must deploy firewalls between servers, you should use IPSEC or VPN tunnels to allow all traffic between those servers to pass through, regardless of source or destination ports. However, experience has taught us that some customers are going to want to restrict traffic, which is why it is possible to configure this range and control the ports that will be used.
Here are two FAQs that have come up internally around this change:
Q: How do the changes to the dynamic port ranges affect AD replication?
A: AD replication relies on dynamically allocated ports for both sides of the replication connection. This means that by default, replication traffic will now use ports higher than 49152 on both domain controllers involved in the transaction.
Q: Can the port that replication traffic uses be controlled?
A: It is still possible to restrict replication traffic to a specific port using the registry values documented in KB 224196.
- Dave Beach
> Generally speaking, we don’t recommend that you restrict traffic between servers on your internal network.
I've been telling this to customers too. Do you know of an official statement from Microsoft which states this? It's always nice to have a proper link for such topics.
Yes and no. We have some KB documentation that has been making this 'don't restrict' guidance:
179442 How to configure a firewall for domains and trusts
832017 Service overview and network port requirements for the Windows Server system
However, they have not yet been updated to reflect these new port assignments. Since their guidance was to not block anything, they are ok for now though. This should all be up to date before Windows Server 2008 comes out.
So I haven't written anything in quite a while and felt compelled to write something I recently ran into.
What people don't realize is that in the world of Compliance we are required to "restrict traffic between servers" even on our internal network. If we don't, it’s a violation and a big one in some cases. Thanks for posting this Ned!