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).
AD needs only a few basic services to be available for normal operations:
Generally, opening these ports between clients and domain controllers, or between domain controllers, will enable AD to function normally. One exception is RPC traffic.
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:
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.
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.