Single server infrastructure design

Updated: April 8, 2010

Applies To: Unified Access Gateway

This topic is designed to help you understand the infrastructure design required for deploying a single Forefront Unified Access Gateway (UAG) server.

This deployment has the following infrastructure design requirements:

  • Selecting a topology location for the Forefront UAG server

  • Joining the Forefront UAG server to a domain or a workgroup

  • Configuring network addressing and routing

  • Configuring DNS servers and settings

Selecting a topology location for the Forefront UAG server

The most common topology locations for a Forefront UAG server are:

  • Behind a frontend firewall─The Forefront UAG server is placed in the internal network, behind a frontend firewall at the corporate edge. The Forefront UAG server has one network adapter that routes to the frontend firewall, and the other is in the internal network.

  • Between a frontend firewall and a backend firewall─The Forefront UAG server is placed in a perimeter network, between a frontend firewall protecting the edge, and a backend firewall protecting the internal network.

If Forefront UAG is located behind an edge or perimeter firewall, verify that the required ports and protocols are open on the firewall, as follows:

Behind a frontend firewall

There are advantages and disadvantages to placing the Forefront UAG server behind the frontend firewall, as follows:

  1. It is the simplest solution, requiring the least amount of hardware and configuration.

  2. It provides a single point of data, as the Forefront UAG server, published servers, and infrastructure servers are all located within the internal network.

  3. It provides a simple configuration for external users who connect via Forefront UAG, and internal users in the internal network can all view the same content.

  4. The main disadvantage of this design is that the corporate internal network is separated from the Internet by a single firewall. Note that the Forefront UAG server itself is protected by Forefront TMG running as a firewall on the Forefront UAG server. Forefront TMG is installed by default during Forefront UAG setup.

If the Forefront UAG server is located behind a frontend firewall, the firewall must be configured to allow the following traffic through to the Forefront UAG server:

  • HTTP traffic (port 80)

  • HTTPS traffic (port 443)

Between a frontend firewall and a backend firewall

There are advantages and disadvantages to placing the Forefront UAG server between a frontend and backend firewall, as follows:

  1. Intranet content, such as servers published by Forefront UAG, can be isolated in the perimeter network and separated from corporate content intended for internal access only.

  2. If content in the perimeter network is compromised or corrupted as a result of Internet access, the integrity of the content in the corporate network is retained.

  3. If the Forefront UAG server is located in the perimeter network, and published servers or infrastructure servers are located in the internal network, the backend firewall must be configured to let the required protocols and ports through the firewall, so that Forefront UAG can effectively publish backend applications and access infrastructure servers, such as authentication servers, as required.

To allow remote endpoints to access the Forefront UAG server located in a perimeter network behind a frontend firewall, the following traffic must be allowed through the frontend firewall:

  • HTTP traffic (port 80)

  • HTTPS traffic (port 443)

Configuring the backend firewall

Configuration of the backend firewall depends upon where backend servers publishing via Forefront UAG are located, and on the location of infrastructure servers, such as Active Directory and authentication servers, used by Forefront UAG. If published backend servers are located in the internal network, allow the following traffic through the backend firewall:

  • HTTP traffic (port 80)

  • HTTPS traffic (port 443)

If infrastructure servers are located in the internal network, some of the following may be required, depending upon the authentication methods used by Forefront UAG:

Infrastructure server Protocol Port

Domain controller

Microsoft-DS traffic

TCP 445

UDP 445

Kerberos authentication

TCP 88

UDP 88

LDAP

TCP 389

UDP 389

LDAPS

TCP 636

UDP 636

LDAP to GC

TCP 3268

UDP 3268

LDAPS to GC

TCP 3269

UCP 3269

DNS

TCP 53

UDP 53

RADIUS server

RADIUS port

UDP 1645 or 1812

SecureID ACE

SecurID ACE port

UJDP 5500

Joining the Forefront UAG server to a domain or a workgroup

The Forefront UAG server can be configured as a member of a domain or a workgroup.

Forefront UAG must be a domain member in the following scenarios:

  1. If you want to add the server to an array of Forefront UAG servers at a later date.

  2. If you want to configure the server as a Forefront UAG DirectAccess server at a later date.

  3. If you want to deploy single sign on using Kerberos constrained delegation to forward session credentials to backend published servers requiring authentication.

  4. If you want to publish the File Access application via a Forefront UAG trunk.

  5. If you want to provide remote clients with access to the internal corporate network using SSTP.

Forefront UAG can be deployed in a domain as follows:

  1. In an existing domain.

  2. Create a domain for the Forefront UAG server. Set up a one-way or two-way trust between the Forefront UAG server domain and the main corporate domain.

For information about joining a domain, see How to join your computer to a domain (https://go.microsoft.com/fwlink/?LinkId=179039). For information about creating a domain, see Creating a domain design (https://go.microsoft.com/fwlink/?LinkId=179040). For information about setting up trusts, see, Checklist: Creating a forest trust (https://go.microsoft.com/fwlink/?LinkId=179041).

For all other scenarios, Forefront UAG can be installed as part of a workgroup. If the Forefront UAG server is a member of a workgroup, a DNS suffix must be defined for the workgroup.

Configuring network addressing and routing

Network addressing and routing requirements for deploying a single Forefront UAG server include the following:

  1. Forefront UAG deployment is highly dependent on correct network configuration. When you configure the internal network during deployment, it will include any subnets that are included in the internal network. When you define the internal network, you must include all subnets that are reachable from the adapter. Note that clients who connect to the internal network using a VPN client connection (Forefront UAG SSL network tunneling) will be able to access all subnets reachable through the internal network adapter.

Configuring DNS servers and settings

DNS infrastructure requirements when deploying a Forefront UAG server include the following:

  1. A public DNS server must be able to resolve the public host name specified by remote endpoints to reach Forefront UAG sites that you create on the Forefront UAG server.

  2. The Forefront UAG server requires internal name resolution to resolve the names and IP addresses of backend published servers, and infrastructure servers such as authentication servers.

  3. Forefront UAG supports alternate access mapping when publishing SharePoint. Alternate access mapping allows you to publish a single SharePoint Web server using multiple different host names. Each SharePoint application on the server is associated with a unique public host name, which is used for remote access to the application. Alternate access mapping requires a public DNS entry for each public host name that might be specified by client endpoints to reach published SharePoint applications.

  4. Forefront UAG supports a new feature that allows you to publish an application using an application-specific host name instead of the portal host name. In order for remote endpoints to reach these applications, a public DNS server must be able to resolve each application-specific host name that you configure. Note that the application-specific host name must resolve to the same IP address as the portal host name.