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 (This was updated on 3-27-2017 to add TCP 5722… Somehow I missed this one for a long time…):
- 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.
- TCP Port 5722 – DFSR/RPC – Sysvol Replication between Domain Controllers.
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.
Cheers!
References:
http://www.windowsnetworking.com/kbase/WindowsTips/WindowsServer2008/AdminTips/ActiveDirectory/WhatAllPortsAreRrequiredByDomainControllersAndClientComputers.html
https://technet.microsoft.com/en-us/library/Dd772723(v=WS.10).aspx
https://technet.microsoft.com/en-us/library/Cc959828.aspx
shorthand
UDP 53
TCP 88
UDP 88
TCP 123
TCP 135
UDP 135
UDP 137
UDP 138
TCP 139
UDP 139
TCP 389
UDP 389
UDP 445
TCP 445
TCP 445
TCP 464
UDP 464
TCP 636
TCP 3268
TCP 3269
TCP 3343
UDP 3343
TCP 5722
TCP 5985-5986
TCP 49152-65535
UDP 49152-65535
135,137,138,139,389,445,464,636,3268,3269,3343,5722,5985,5986,49152-65535
Pingback: Add Ubuntu 14.04 LTS Server to a Windows Active Directory Domain – Fullest Integration « KiloRoot
Pingback: Filezilla Server + Microsoft Active Directory LDAP Authentication « KiloRoot
Pingback: PWM – Open Source Password Self Service for LDAP directories – Yay! « KiloRoot
Pingback: OpenFire + Microsoft Active Directory + Security = Awesome Enterprise Instant Messenger « KiloRoot
Pingback: Setting up OpenVPN Access Server on Ubuntu 13 « KiloRoot
Should we lock the port rules down to the IPs of the Domain Controllers?
It’s been a while since I was an MS Windows Sys Admin so take this with a grain of salt as it might be a bit outdated… That caveat provided, when I was a sys admin, DC’s always had fixed/static IP addresses. So to that end, I would say yes, it makes perfect sense to use the DC IP addresses in your firewall rules and from what I remember that is exactly what we did. We kept one or more lists of IP addresses in our Fortigate configs for our domain controllers in Azure and in our 2 physical data centers and we used those lists on rules for traffic to/from the DC’s. Anytime you can be more specific, typically the more secure things are – but the tradeoff is that you have a heavier administrative burden. In this case, it shouldn’t be that much of a burden as long as your firewalls are fairly modern and support constructs like lists that you can just add/remove IP addresses from (vs. having to create individual rules for each DC).