Network isolation of domain controllers: no Internet, controlled flows and an active firewall
Domain controllers must be reachable by the whole estate for authentication, which often leads organisations to leave them wide open. Yet there is a large gap between "reachable for directory services" and "reachable for everything". Network isolation shrinks both the attack surface and the options for data exfiltration.
No Internet browsing from a DC
A domain controller has no reason to visit websites, read email or download tools. Every browsing session opened from a DC exposes a Tier 0 account to uncontrolled content. The rule must be technical, not just organisational: the proxy rejects requests from domain controllers except to a short list of required destinations, and no browser is used on these servers.
Legitimate exceptions exist but can be counted on one hand: the update service (ideally an internal WSUS server or a patch management solution), the Defender for Identity or Defender for Endpoint cloud service, and an external time source for the PDC emulator. Each must be documented and restricted to its endpoints.
Restricting outbound traffic
People naturally think about inbound flows, but outbound traffic from a DC matters just as much. A domain controller that can open an SMB or HTTP connection to any machine can be coerced into authenticating to it, which feeds NTLM relay attacks. It can also serve as a launch pad for data exfiltration. In practice, a DC needs to reach other DCs (replication, DNS), its time sources, its update, monitoring and backup servers, and a few identified cloud services. Everything else can be denied.
Administration only from dedicated workstations
Administration protocols (RDP, WinRM and PowerShell remoting, MMC consoles over RPC) should only be accepted from privileged access workstations (PAWs) or a Tier 0 administration network. An administrator who opens an RDP session to a DC from an office workstation exposes their credentials to anything running on that workstation. Filtering happens at two levels: on the network (access lists, segmentation) and on the DC itself through Windows Firewall.
Windows Firewall on domain controllers
Turning off Windows Firewall on DCs "to avoid problems" is still common. It is a mistake: the firewall should be on for every profile, configured through Group Policy rather than locally, with logging of dropped packets enabled. Inbound rules for directory services stay open to the whole estate, while administration rules are limited to PAW address ranges. Disable local rule merging so that an administrator cannot quietly add an exception.
The main ports to know are:
| Service | Port(s) | Recommended scope |
|---|---|---|
| DNS | TCP/UDP 53 | whole estate |
| Kerberos and password change | TCP/UDP 88, TCP/UDP 464 | whole estate |
| LDAP, LDAPS | TCP/UDP 389, TCP 636 | whole estate |
| Global catalog | TCP 3268, TCP 3269 | whole estate |
| SMB (SYSVOL, NETLOGON) | TCP 445 | whole estate |
| RPC endpoint mapper and dynamic ports | TCP 135, TCP 49152-65535 | whole estate (replication, services) |
| Time (NTP) | UDP 123 | whole estate |
| Active Directory Web Services | TCP 9389 | admin workstations |
| RDP, WinRM | TCP 3389, TCP 5985/5986 | PAWs only |
This list covers common needs; some roles (DHCP, file replication, third-party services installed on DCs) add more. Check Microsoft's documentation on the ports used by Active Directory and validate every rule in a test environment.
Fewer roles, fewer ports. Every additional role installed on a DC (print server, file server, application agent) opens flows and widens the attack surface. A domain controller should stay a domain controller.
What an audit checks
- the state of Windows Firewall on every DC, whether rules come from Group Policy, and logging;
- whether a DC can browse the Internet or reach arbitrary destinations;
- the source addresses allowed for RDP, WinRM and administration consoles;
- unnecessary roles and software installed on domain controllers.