Active Directory Firewall Ports — The Complete Reference

The Minimum Viable AD Port Set

If you need a list to hand the network team this afternoon, this is it. These ports cover domain controller to domain controller replication and member server logon in a single-forest environment running currently supported versions of Windows Server. The sections that follow either explain one of these rows in depth or add an application on top.

Think of the RPC endpoint mapper on port 135 as the switchboard in an old hotel. You ring the switchboard, ask for the replication service, and the operator tells you it is on room extension 51204. If the firewall lets you reach the switchboard but not the extension, you get a perfectly successful conversation that ends in silence — which is exactly what Error 1722: The RPC server is unavailable looks like from the other side.

Domain Controller to Domain Controller

Two domain controllers replicating with each other are peers, not client and server. Either one can initiate, so the rules have to work in both directions. On top of the minimum set above, DC-to-DC traffic adds the replication engines themselves.

Two rows deserve a note. DFSR on port 5722 is version-specific: Microsoft assigned it for Windows Server 2008 and 2008 R2 domain controllers and dropped it from Server 2012 onwards, where DFSR simply uses a dynamically allocated high port like everything else. If your firewall rules still carry 5722 and your DCs are 2012 or later, the rule is dead weight — harmless, but it tells you the ruleset has not been reviewed in a decade.

ICMP is the one people delete on principle. The Microsoft LDAP client uses ICMP echo to check that a server with a pending LDAP request is still on the network, and the Windows redirector uses it when locating a server through DFS. Block it entirely and you do not lose authentication, but you inherit slow, hard-to-diagnose timeouts. Allowing ICMP to domain controller addresses specifically is the usual compromise.

Member Servers and Workstations to a DC

This is the direction most segmentation projects get wrong, because logon appears to work from a test machine long before Group Policy, password changes, or a management tool start failing. All of the following is client-initiated toward the domain controller.

Group Policy is worth calling out separately because it fails so distinctively. Microsoft’s requirement is that a client reach a domain controller over Kerberos, LDAP, SMB and RPC. Miss any one of those and policy does not apply or refresh — which surfaces as a policy that worked yesterday quietly going stale rather than as an error anyone reports. Remote gpupdate initiated from a management console adds RPC and WMI inbound to the target machine on 135 and the dynamic range, which is a different rule in a different direction from everything above.

For a walk through what actually happens during a logon, and why so much of it is Kerberos, the authentication and Kerberos post covers the ticket exchange these ports carry.

Trusts, Cross-Forest, and RODCs

A trust does not introduce new protocols so much as it extends the existing ones across a boundary you were probably filtering deliberately. The port set for a trust between two Windows Server 2003-or-later domains is effectively the DC-to-DC list: DNS, Kerberos, LDAP, the Global Catalog, SMB, the endpoint mapper, and the dynamic RPC range, in both directions between the domain controllers of each side.

Three specifics catch people out. W32Time over UDP 123 across an external trust is only required if you have deliberately pointed the time service at a server on the other side; it is not needed for the trust itself. UDP 138 reappears when name resolution falls back to NetBIOS, which happens with legacy or Samba-based domain controllers on the far end. And Global Catalog access matters more across a forest trust than inside a domain, because universal group enumeration for a foreign principal has to happen somewhere.

Read-only domain controllers are the interesting case for a branch or DMZ. An RODC uses the same inbound port set as a writable DC for its own clients, but its outbound relationship is one-way: it pulls from a writable partner and never pushes. That gives you a rule you can actually justify to a security team — inbound AD ports from the branch subnet to the RODC, and outbound replication from the RODC to a named set of hub DCs, with no inbound replication path from the branch into the core at all. Password changes are the exception. An RODC holds a read-only copy of the database, so a change has to be made on a writable domain controller and replicated back — which means the outbound path from the branch has to be genuinely functional rather than decorative, and an account whose password is not cached on the RODC needs to reach a writable DC to authenticate at all.

When a trust looks configured but authentication across it fails, the diagnosis is usually one of these paths rather than the trust object itself — the trust relationship failed covers that specific symptom.

Pinning the Dynamic RPC Range

Sooner or later a firewall team will refuse 49152-65535, and they are not being difficult: that is sixteen thousand ports. The supported answer is to pin Active Directory’s RPC services to specific static ports, so the endpoint mapper hands out an address the firewall already allows.

This is done with two registry values, and the mistake everyone makes is setting only the first one.

# Static port for the directory service itself (NTDS): replication, DRS, SAM, LSA.
# HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
#   Value: TCP/IP Port      Type: REG_DWORD      Data: an available port
# Requires a reboot to take effect.

# Static port for the Netlogon RPC interface.
# HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
#   Value: DCTcpipPort      Type: REG_DWORD      Data: a DIFFERENT available port
# Requires only a restart of the Netlogon service.

If you set both values to the same port, Netlogon logs error event 5809 to say the port is in use, and you should pick another. Confusingly, the same event is also logged harmlessly when you restart Netlogon on a correctly configured DC, because of how the RPC runtime hands over its server ports. On a healthy DC with two distinct ports configured, that one is noise.

DFSR needs pinning separately, because SYSVOL replication does not travel over the NTDS port:

# Pin DFS Replication to a single static RPC port on a named member.
# Omit /Member and dfsrdiag targets the local computer.
dfsrdiag StaticRPC /port:nnnnn /Member:dc02.corp.example.com

On current Windows Server builds the Set-DfsrServiceConfiguration cmdlet does the same job from PowerShell, and is the better choice if you are scripting the change across a set of DCs. Check the cmdlet’s own help for the parameter name on your build rather than assuming it matches the dfsrdiag switch.

You can also move the ephemeral range itself, which changes what the operating system allocates for outbound connections generally rather than pinning a specific service:

# Show the current dynamic port range for TCP and UDP.
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp

# Narrow the range to 1000 ports starting at 10000 (so 10000-10999).
# Minimum range is 255 ports; minimum start port is 1025.
netsh int ipv4 set dynamicport tcp start=10000 num=1000
netsh int ipv4 set dynamicport udp start=10000 num=1000

Where this bites: pinning is a supported configuration, not a free one. Microsoft has published fixes for long logon times and for replication failing with RPC errors after a static NTDS port was set, so a domain controller that is behind on patching is a poor candidate. Restricting the range too aggressively also risks port exhaustion on a busy DC — you have taken away sixteen thousand ephemeral sources and given back a few hundred. Pin the services, and leave the general dynamic range alone unless you have a measured reason.

Certificate Services (AD CS)

AD CS has two completely separate traffic patterns, and conflating them is why PKI firewall rules are so often wrong. Enrollment is RPC/DCOM. Revocation checking is plain HTTP. They travel different paths, and the second one is the one that silently destroys authentication.

Revocation checking is the number one silent failure in a segmented PKI, and it is worth understanding why it is silent. When a client validates a certificate, it fetches the CRL from the URL baked into the certificate’s CDP extension. If that URL is unreachable, the client does not fail fast — it waits for a timeout, then treats revocation status as unknown. Depending on what is validating, that surfaces as a login that takes ninety seconds, an LDAPS bind that intermittently fails, a smart card that works in the office and not in the DMZ, or a service that starts fine and then stalls on its first outbound TLS handshake. Nothing in that list says “CRL”.

There is a related failure that looks like a firewall problem and is not: an expired domain controller certificate breaks LDAPS while leaving plain LDAP working, which is covered in LDAPS fails after the DC certificate expired. The broader PKI design is in the Active Directory Certificate Services post.

Configuration Manager (SCCM / MECM)

Configuration Manager has the largest port surface of anything covered here, because it is really a dozen role-to-role relationships rather than one product. The saving grace is that most client-facing traffic is HTTP or HTTPS on ports you can change.

Two PXE traps are worth naming. TFTP listens on UDP 69 but replies from a dynamically allocated high port, so a stateless rule that only permits UDP 69 lets the request out and drops every reply. And during the actual PXE boot, the port the network card selects is chosen by the card’s firmware, not by Windows — it is bounded only by RFC 1350, meaning anything from 0 to 65535. PXE across a firewalled boundary is genuinely awkward, and a local DP in the segment is usually the honest answer.

Operations Manager (SCOM)

SCOM is refreshingly compact by comparison: agents talk to a management server on one port, and almost everything else is either SQL or a console.

The pattern to take away is that the steady-state agent requirement is a single outbound port, but the installation requirement is the full file-and-print and dynamic RPC set, because the management server pushes the agent using the same mechanisms as any other remote install. That is why so many DMZ SCOM deployments are described as “not working” when the agent was simply never installed. Deploy the agent manually with the MSI, and 5723 outbound is genuinely all you need afterwards.

One documented constraint to plan around: Operations Manager does not support LDAP over SSL, so do not build a rule set that assumes SCOM will reach a domain controller on 636.

CrowdStrike Falcon

Falcon is the section where the correct answer is much shorter than people expect, and getting it wrong costs you unnecessary exposure rather than a broken service.

What does need care is the destination set. Falcon sensors connect to region-specific cloud endpoints — the ts01-*.cloudsink.net hosts and associated *.crowdstrike.com API endpoints — and the exact hostnames differ between US-1, US-2, EU-1 and GovCloud tenancies. Do not copy an allowlist from a blog post, including this one: the authoritative list lives in the CrowdStrike support portal for your tenant, and it changes. Take the hostnames from there.

On proxies: the sensor supports proxying, but if the proxy performs TLS inspection you need to exclude the CrowdStrike destinations from interception. The sensor validates the certificate chain it expects, and an inspecting proxy substitutes its own — which produces a sensor that installs cleanly, reports as installed locally, and never appears in the console. That specific failure mode is worth checking before anyone starts examining firewall logs.

Internal Web Applications and AD

An internal web application that uses Windows Authentication is not just an HTTP service. It is a Kerberos participant, and it needs a path to the directory that has nothing to do with the port users connect on.

The row that catches people is Kerberos from the user to the domain controller. When a browser hits an intranet site configured for Windows Authentication, the client requests a service ticket for that site’s SPN from a DC and presents it to the web server. Put the users in a segment that cannot reach a DC on 88, and the site does not fail with an authentication error — it falls back to NTLM, or prompts for credentials repeatedly, which sends everyone hunting through IIS configuration for a problem that is on the network.

Constrained delegation adds a second hop with its own requirements. The web server itself must reach a domain controller to request a ticket on the user’s behalf, so the server segment needs Kerberos and LDAP outbound to a DC even though no user traffic goes that way. When delegation is configured correctly and still fails, the causes are usually SPN registration rather than ports — Kerberos constrained delegation not working works through that case in detail.

For AD FS, note the asymmetry in the 49443 rule. Client certificate authentication needs TCP 49443 inbound on the firewall between clients and the Web Application Proxy, but not on the firewall between the proxy and the federation servers. Microsoft also warns that no other service on those servers should be using 49443, which is worth checking on a shared host.

The Ports Everyone Forgets

These are the rules that get discovered three weeks after a segmentation project is declared complete, usually by someone who cannot print.

Two honest caveats. Syslog is conventionally UDP 514, and TCP 514 or 6514 for TLS, but that is a protocol convention rather than a Microsoft service port — take the real value from your collector’s configuration. Backup agents are entirely vendor-specific and frequently use a control port plus a dynamically negotiated data channel; there is no useful generic answer, and guessing produces a rule that passes a firewall review and fails a restore. Get the port list from the vendor for the version you are running.

Windows Event Forwarding deserves a specific mention because its direction surprises people. In the common source-initiated setup, the forwarding computers connect outbound to the collector over WinRM, so the rule you need is from the monitored estate to the collector, not the reverse. If you have modelled it as a management tool reaching in, the rules will be backwards.

“Just Open Everything Between the DCs”

This request appears in every AD firewall project, usually from the AD team, and it is worth understanding why it is both reasonable and wrong.

It is reasonable because the dynamic RPC range genuinely is enormous, the interactions genuinely are complex, and a permit-any rule between two domain controllers does eliminate an entire class of tickets. Nobody asking for it is being lazy.

It is wrong because domain controllers are the highest-value target in the estate, and a permit-any rule between them means that an attacker who compromises one has unrestricted lateral movement to every other. It also destroys your ability to answer the question “what does this DC actually talk to?”, which you will want during an incident. And in practice it papers over the real problem: nobody documented what the environment needs, so the ruleset can never be reviewed or reduced.

What to offer instead, in the order network teams tend to accept it. Start with the fixed-port set — twelve well-known ports with a clear justification each, which is a rule sheet a security team can actually approve. Then handle the dynamic range by pinning NTDS, Netlogon and DFSR to specific static ports, which converts “sixteen thousand ports” into “three more ports”. Where the boundary is genuinely hostile, encapsulate the whole conversation: Microsoft’s documented alternative is IPsec, which reduces the firewall rule to ESP (IP protocol 50), ISAKMP on UDP 500, and NAT-T on UDP 4500 regardless of what is inside the tunnel.

Proving a Port Is Actually Open

A firewall rule existing and a port being reachable are different claims. These are the tools, roughly in order of how much they tell you.

# Cheapest check: is this single TCP port reachable from here?
Test-NetConnection -ComputerName dc02.corp.example.com -Port 389

# Ask the RPC endpoint mapper what it is actually advertising.
# Querying 135 with -e returns every endpoint currently registered.
portqry -n dc02.corp.example.com -e 135 -p tcp

# Probe a range. Note the separator is a colon, not a hyphen.
portqry -n dc02.corp.example.com -r 49152:49200 -p tcp

# Query several specific ports in one pass, in the order given.
portqry -n dc02.corp.example.com -p both -o 88,135,389,445,464

# Confirm the local dynamic port range matches what the firewall allows.
netsh int ipv4 show dynamicport tcp

# Is replication actually succeeding, and with which partners?
repadmin /showrepl
repadmin /replsummary

# Microsoft's own replication and connectivity tests.
dcdiag /test:replications
dcdiag /test:connectivity

# Which DC does this machine believe it should be using, and is the channel healthy?
nltest /dsgetdc:corp.example.com
nltest /sc_query:corp.example.com

The order matters. Test-NetConnection proves a single TCP path and nothing else. PortQry against 135 is the one that earns its keep on RPC problems, because it does not just test the port — it enumerates what the endpoint mapper is handing out, so you see the dynamic ports the service is genuinely using and can test those specifically. Then repadmin /showrepl tells you whether the directory agrees that any of it is working.

One documented quirk: a PortQry query to UDP 389 may not work correctly against modern domain controllers. Use nltest to check the DC locator service on UDP 389 rather than concluding the port is blocked.

When these tests point at RPC specifically, replication error 1722 walks through the full diagnosis, and Windows Firewall with Advanced Security covers the host-based half of the problem.

Gotchas That Cost You a Change Window

Final Thoughts

The reason AD firewall work is unpleasant is not that the port list is long. It is that the failures are asymmetric: nearly every missing rule produces a delayed, partial, or intermittent symptom rather than a clean error. Group Policy goes stale. Password changes fail while logon works. A certificate validates in one segment and hangs in another. By the time anyone reports it, the change that caused it is weeks old and off the suspect list.

The defence is to treat the port list as documentation of what the environment actually does, rather than as a request form. Write down which host needs to reach which host and why. Pin the RPC services so the dynamic range stops being the whole conversation. Prove reachability with PortQry and repadmin rather than trusting the rule sheet. Then the next segmentation project starts from a list instead of an argument.