3.6 Trusts and firewalls

Many enterprise environments require Windows trust relationships to be set up between domains or forests that are crossing firewalls. Because in Windows 2000 and later the true security boundary is the forest, this has become a common practice between different Windows forests: Some organizations, for example, maintain separate internal and external Windows forests that are separated by a firewall. Table 3.5 gives an overview of common multiforest enterprise scenarios and their trust-related firewall requirements, both for inbound and outbound traffic.

Table 3.5: Firewall Port Configuration for Multiforest Scenarios

Scenario	Inbound Ports		Outbound Ports
Trust setup on both sides from an internal forest (two-way trust)	LDAP	389 UDP and TCP
	MS DS	445 TCP
	Kerberos	88 UDP
Trust validation from an internal forest domain controller to an external forest domain controller (outgoing trust only)	LDAP	389 UDP and TCP
	MS DS	445 TCP
	DCE endpoint resolution—portmapper	135 TCP
	Netlogon	fixed port
Using object picker on an external forest to add objects in an internal forest to groups and ACLs			LDAP	389 UDP and TCP
			LSA	fixed port
			Netlogon	fixed port
			Kerberos	88 UDP
			DCE endpoint resolution—portmapper	135 TCP
Set up a trust on the external forest from the external forest			LDAP	389 UDP and TCP
			MS DS	445 TCP
			Kerberos	88 UDP
Network logon feature from an internal forest domain controller to an external forest domain controller with Kerberos authentication	MS DS	445 TCP
	Kerberos	88 UDP
Network logon feature from an internal forest domain controller to an external forest domain controller with NTLM authentication			DCE Endpoint resolution—portmapper	135 TCP
			Netlogon	fixed port

Windows trust setup and maintenance heavily rely upon RPCs. One of the key problems with RPCs in a firewall environment is its use of dynamic port allocations (see the previous side note). In order to limit the amount of firewall ports that must be opened to enable trust-related RPC traffic to pass through the firewall, Windows Server 2003 includes the following registry keys:

• The LSA RPC port, which is used for trust creation and access to the LSA Policy database, can be defined using the “TCP/IP Port” entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ NTDS\Parameters.

• The Netlogon RPC port, which is used for NTLM and secure channel setup, can be defined using the “DCTcpipPort” entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ Netlogon\Parameters.

  Remote Procedure Calls (RPCs) and Dynamic Service-Port Mappings

  An important goal behind the development of the remote procedure call (RPC) protocol was to build a solution for the limited number of service ports available in the TCP and UDP protocols. In both TCP and UDP, ports are defined in a 2-byte field, which limits the number of ports to 65,536.

  Instead of using static service-port mappings, RPC provides a dynamic service-port mapping function. In RPC, incoming RPC calls are mapped to a variable port in the 1,024 to 65,535 range. Although RPC uses variable service ports, it needs a unique way to identify services. The RPC protocol resolves this need by using a special service identifier and a dedicated Portmapper service. The unique RPC identifier is called the RPC service number. Service numbers are defined in a 4-byte field, which provides up to 4,294,967,296 possible service numbers. The Portmapper service listens on a static port (TCP or UDP port 135). The service exists primarily to map the unique RPC service number on a variable TCP/ UDP port. Thus, RPC can provide both a unique way to identify RPC services and a way to dynamically allocate the scarce number of TCP/UDP service ports.

  Figure 3.24 illustrates how this dynamic port allocation works. In Step 1, the RPC server starts and registers with the RPC Portmapper service. The RPC portmapper maps the RPC service number to a port in the range 1,024 to 65,535. In Step 2, the Portmapper returns the port to the RPC server. The first two steps are known as the RPC registration steps. The RPC client then wants to connect to the RPC server. To find out the exact port on which the server is listening, the RPC client contacts the Portmapper (Step 3). The Portmapper then maps the RPC service number it received from the client to the server’s port and returns the number to the client (Step 4). Finally, the RPC client connects to the server (Step 5), and the server replies to the client (Step 6).

  
  Figure 3.24: RPC operation.