Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

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.

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.