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.




Windows Server 2003 Security Infrastructures. Core Security Features of Windows. NET
Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)
ISBN: 1555582834
EAN: 2147483647
Year: 2003
Pages: 137
Authors: Jan De Clercq

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net