How does Active Directory communicate?

Active Directory (AD) relies on several communications services to communicate with client computers and between domain controllers. The variety of communications protocols used reflects the complex nature both of AD and of the industry-standard protocols that AD implements, such as Kerberos and the Lightweight Directory Access Protocol (LDAP). Understanding how AD communicates can be critical when you're working with domain controllers or clients that are separated from domain controllers by firewalls or other portfiltering devices (such as routers).

Basic Communications

AD needs only a few basic services to be available for normal operations:

  • User Datagram Protocol (UDP) port 88 is used for Kerberos authentication. Transmission Control Protocol (TCP) port 88 can also be used, although it's less common.
  • TCP and UDP ports 135 are needed for remote procedure call (RPC) endpoint mapping. RPCs are used for a number of domain controller-to-domain controller and client-todomain controller operations. Unfortunately, not all communications take place over port 135, as I'll discuss later.
  • TCP port 139 and UDP port 138 are needed for file replication between domain controllers. This port combination is the standard NetBIOS session service port set.
  • UDP port 389 handles LDAP queries and is used for normal domain controller operations.
  • TCP and UDP ports 445 are used for file replication and are the standard Windows file sharing ports.
  • TCP and UDP ports 464 are the Kerberos password change protocol ports.
  • TCP port 593 is used by the RPC over HTTP transport. Although you don't technically need this port for normal operations, I'll discuss later how this feature can make working with domain controllers through firewalls a bit easier.
  • TCP port 636 is for LDAP over Secure Sockets Layer (SSL), which is the default LDAP methodology for Windows Server 2003 and later.
  • TCP port 3268 and 3269 handle Global Catalog (GC) queries. Port 3269 handles secure queries. Any domain controller that needs access to a GC or that is acting as a GC server will use these ports.
  • TCP and UDP ports 53 are used to communicate with Domain Name System (DNS), which is a vital part of AD communications.

Generally, opening these ports between clients and domain controllers, or between domain controllers, will enable AD to function normally. One exception is RPC traffic.

RPC Endpoint Mapping

Most RPC communications first start on TCP port 135. However, that's merely the RPC endpoint mapper service. Its function is to select a new destination port for further communications in that RPC session. Exchange Server is a major user of RPC endpoint mapping, and it's very difficult to get Exchange traffic through a firewall as a result. The range of potential endpoint addresses used by RPC communications is huge, essentially requiring the entire firewall to be opened to allow all the possibilities. The ports selected by the endpoint mapper can range from TCP 1024 to TCP 65535.

Fortunately, you can force AD to always map endpoints to specific ports. The Internet Assigned Numbers Authority (IANA) has set aside ports 49152 to 65535 for private port assignments, so choose ports from this range and force AD to always use them. You'll then be able to open a much smaller range of ports in your firewalls.

To force port selection, modify the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. You'll need to create or modify a DWORD value named TCP/IP Port, and set it to whichever port you're going to use. However, there are some downsides to this modification:

  • You'll need to modify every domain controller on your network; otherwise, they won't be able to communicate properly. You're effectively disabling endpoint mapping, so all domain controllers will have to be manually told which port to use.
  • Your domain controllers will have to work a bit harder to handle the same number of connections. The servers communicate less efficiently when forced to use a single port for all communications because they can't rely on the port number to identify individual "conversations."


Windows Server 2003 offers an exciting new communications protocol: RPC packets embedded within easily transported HTTP packets. This protocol is called RPC over HTTP, and it's handled by an RPC proxy DLL that's installed as an optional IIS 6.0 component.

Unfortunately, the computer initiating a conversation must choose to use RPC over HTTP, and Windows isn't currently designed to do so for domain communications. The only practical use for RPC over HTTP at the moment is Outlook 2003 communications with Exchange Server 2003; RPC over HTTP is invaluable there because it allows an RPC-heavy client such as Outlook to communicate through easy-to-manage HTTP ports. Hopefully, in the future, RPC over HTTP will become a more widespread means of communication.

Choosing Your Battles

If you're in a situation in which you have to have AD communications passing through a firewall, try to choose the path of least resistance. For example, domain controller-to-domain controller communications are amongst the most difficult as a result of the wide range of protocols in use and the need for constant RPC connectivity. However, client-to-domain controller communications are significantly less complicated, so placing a domain member in a perimeter network, for example, will be easier to deal with than placing a domain controller there.

If you absolutely must have a firewall between domain controllers, you'll need to restrict the ports they use. The File Replication Service (FRS) will need to be restricted, as will general communications. I explained earlier how to force an RPC port for general communications; Microsoft can help you with other types of traffic.

See the Microsoft articles "Restricting Active Directory Replication Traffic to a Specific Port" for information about restricting AD replication traffic and "How to Configure a Firewall for Domains and Trusts" for information about configuring firewalls to support domain and trust communications. In addition, see "How to Restrict FRS Replication Traffic to a Specific Static Port" for information about restricting FRS traffic.