In the series of posts this month we’ve been looking at network ports relevant to security administrators. This note explores the ports used for Active Directory (AD) communications, which is a topic particularly relevant for allowing AD traffic across a firewall. For instance, you may be wondering which ports to open to allow AD replication across internal subnets, or to allow an AD member server on a screened subnet to authenticate to a domain controller on another subnet.
AD-Related Ports
Active Directory communications involve a number of ports, some of which are more familiar to network and security administrators than others. These were outlined in the Active Directory Replication over Firewalls article by Steve Riley:
- RPC endpoint mapper: port 135 TCP, UDP
- NetBIOS name service: port 137 TCP, UDP
- NetBIOS datagram service: port 138 UDP
- NetBIOS session service: port 139 TCP
- SMB over IP (Microsoft-DS): port 445 TCP, UDP
- LDAP: port 389 TCP, UDP
- LDAP over SSL: port 636 TCP
- Global catalog LDAP: port 3268 TCP
- Global catalog LDAP over SSL: port 3269 TCP
- Kerberos: port 88 TCP, UDP
- DNS: port 53 TCP, UDP
- WINS resolution: port 1512 TCP, UDP
- WINS replication: 42 TCP, UDP
- RPC: Dynamically-assigned ports TCP, unless restricted
For a full listing of AD-related services, see Microsoft’s support article 832017 Service Overview and Network Port Requirements for the Windows Server System.
Which of these ports actually need to be allowed through the firewall depends on the scenario you’re implementing and on your environment. For instance, support for NetBIOS services may unnecessary in situations where you have newer Windows systems supporting the SMB over IP protocol. Similarly, newer Windows environments make use DNS, instead of Windows for name resolution.
AD Replication
The ports that need to be open to facilitate cross-firewall AD replication differ, depending on the versions of Microsoft Windows in your environment. Microsoft provides OS-specific guidelines in its Active Directory and Active Directory Domain Services Port Requirements article. For instance, replication between servers that use Windows 2000 or 2003 require the following ports open bidirectionally on the firewall that’s between the servers:
- RPC endpoint mapper: port 135 TCP
- LDAP: port 389 TCP, UDP
- LDAP over SSL: port 636 TCP
- Global catalog LDAP: port 3268 TCP
- Global catalog LDAP over SSL: port 3269 TCP
- DNS: port 53 TCP, UDP
- Kerberos: port 88 TCP, UDP
- SMB over IP (Microsoft-DS): port 445 TCP
- RPC: Dynamically-assigned ports TCP, unless restricted
To restrict the use of RPC ports, follow instructions in Microsoft’s support article 224196 Restricting Active Directory Replication Traffic and Client RPC Traffic to a Specific Port and a TechNet blog entry Dynamic Client Ports in Windows Server 2008 and Windows Vista.
Authentication to AD
AD uses the following ports to support user and computer authentication, according to the Active Directory and Active Directory Domain Services Port Requirements article:
- SMB over IP (Microsoft-DS): port 445 TCP, UDP
- Kerberos: port 88 TCP, UDP
- LDAP: port 389 UDP
- DNS: port 53 TCP, UDP
- RPC: Dynamically-assigned ports TCP, unless restricted
Tunneling AD Traffic Using IPSec
If you don’t like having to open this many ports, you could use IPSec to tunnel the traffic across the firewall. You could use ESP with encryption disabled, so the packets would still be cryptographically signed and tunneled, but your intrusion detection systems (IDS) would still have visibility into the traffic.
Jason Fossen, who teaches the Securing Windows class at SANS, shared with us additional insights regarding the use of IPSec:
Because IPSec connections can be limited to those users and computers in specified global groups, is tightly integrated into the host-based Windows Firewall (which would be configured on all DMZ servers and participating controllers), and can optionally be tied into a Network Access Protection (NAP) infrastructure, the use of IPSec can provide benefits the perhaps outweigh the IDS/IPS hassles.
The Use of AD in the DMZ or a Screened Subnet
Jason Fossen also shared his thoughts on architecting AD in environments where some Windows servers reside close to the network’s perimeter, such as in the DMZ or a screened subnet. He recommending implementing a separate forest for DMZ servers that need to be domain members (perhaps with a one-way cross-forest trust to the internal forest), rather than joining DMZ servers to the internal forest directly. Jason continued:
The DMZ controller(s) will be located in a new perimeter network attached to a firewalling device. When implementing a cross-forest trust, after configuring groups and permissions on the DMZ servers (which requires LDAP traffic), the only traffic that must be allowed through the firewall is Kerberos. If the DMZ servers must be joined to the internal forest, then it’s better to place Read-Only Domain Controllers (RODC) in another perimeter network of the firewall for the sake of the DMZ servers.
Also, with the use of PKI, RADIUS, reverse proxy servers, etc., it has become less necessary to either join DMZ servers to the internal forest or to establish a one-way cross-forest trust from the DMZ forest to the internal one, even when users must authenticate with the internal forest credentials.
