If you are in a decently secure network your Active Directory domain controllers are “silo’d” off from all of your workstations and member servers. This is good, however, if your internal firewalls aren’t configured properly it can cause all kinds of headache for day-to-day domain operations.

Update: You might also want to checkout this article about Windows File Sharing – what ports are used and why? It answers a lot of basic questions about Windows File sharing technology and debunks a lot of misinformation (a lot of which you probably believe if you have been a Windows Admin for any length of time like myself…): Windows File Sharing: Facing the Mystery

So to that point, I have compiled a quick list of ports that need to be open in both directions for your domain to function appropriately:

  • TCP and UDP Port 88 – Kerberos authentication
  • TCP and UDP Port 135 – domain controllers-to-domain controller and client to domain controller operations.
  • TCP Port 139 and UDP 138 – File Replication Service between domain controllers.
  • UDP Port 389 – LDAP to handle normal queries from client computers to the domain controllers.
  • TCP and UDP Port 445 – File Replication Service
  • TCP and UDP Port 464 – Kerberos Password Change
  • TCP Port 3268 and 3269 – Global Catalog from client to domain controller.
  • TCP and UDP Port 53 – DNS from client to domain controller and domain controller to domain controller.

That was the list I found at my first referenced URL. However via experience I discovered you will want either or possibly both of the following port ranges open:

  • TCP Port Range 1025-5000 – If your network has any Server 2003 R2 or older domain controllers. This is the default dynamic range for RPC connections.
  • TCP Port Range 49152-65535 – If your network has any Server 2008 or newer domain controllers. This is the new dynamic port range for RPC connections.

Finally, in addition to that, I found it odd that most websites didn’t mention that you should probably open up the port for NTP (Network Time Protocol) as best practice (and I believe default behavior for member servers) synchronize their clocks via the domain controller. If you miss this one you will end up with all kinds of odd behavior on your network as your device clocks slowly come out of sync. So…

  • UDP Port 123 – Network Time Protocol

Update 2: If you are having some trouble with time syncing correctly on either your Domain Controllers or Member Servers, you might want to check out some of these articles:
NTP Circular Time Sync Issue – Hyper-V
Force a Domain Controller to Sync its Clock with an External Time Server

One final side note; if you are using the older dynamic TCP port range for RPC of 1025 – 5000, this has the consequence of also opening up remote desktop protocol (RDP) on TCP 3389. If you are security conscious that may be an unintended consequence, in which case you need to add an explicit deny rule on your firewall or routing device to block this.

That covers it! Hopefully this will help all of you other Windows and network admins out there that have to deal with this stuff every day.




1 of 1

Leave a Reply