Unified Access Gateway Architecture

This chapter is one of a series that make up the Omnissa Workspace ONE and Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Omnissa Workspace ONE and Omnissa Horizon solutions. This chapter provides information about architecting Omnissa Unified Access Gateway.

Introduction

Omnissa Unified Access Gateway is an extremely useful component within an Omnissa Workspace ONE and Horizon deployment because it enables secure remote access from an external network to a variety of internal resources. Unified Access Gateway supports multiple use cases:

  • Per-app tunneling of native and web apps on mobile and desktop platforms to secure access to internal resources through the Tunnel service.
  • Secure on-premises email infrastructure that grants access only to authorized devices, users, and email applications based on managed policies. This capability leverages the Secure Email Gateway service integrated with Omnissa Workspace ONE Unified Endpoint Management (UEM).
  • Access from Omnissa Workspace ONE Content to internal file shares or SharePoint repositories by running the Content Gateway service.
  • Reverse proxying of web applications.
  • Identity bridging for authentication to on-premises legacy applications that use Kerberos or header-based authentication.
  • Secure external access to desktops and applications on Omnissa Horizon Cloud Service, and Omnissa Horizon 8.

When providing access to internal resources, Unified Access Gateway can be deployed within the corporate DMZ or internal network, and acts as a proxy host for connections to your company’s resources. Unified Access Gateway directs authenticated requests to the appropriate resource and discards any unauthenticated requests. It also can perform the authentication itself, leveraging additional authentication methods when enabled.

A screenshot of a computer</p>
<p>Description automatically generated

Figure 1: Unified Access Gateway Logical Architecture Overview

Unified Access Gateway, and all its edge services, support being deployed across VMware vSphere, Microsoft Azure, and Amazon Web Services. For Microsoft Hyper-V, only Tunnel, Content Gateway, and Secure Email Gateway edge services are supported.

Table 1: Implementation Strategy for External Access for the Entire Workspace ONE Environment

Decision

Multiple Unified Access Gateway appliances were deployed on vSphere to support the whole Workspace ONE environment.

Justification

This strategy provides external access for Workspace ONE users to internal resources, such as web applications, file repositories, and virtual desktops and applications.

On Omnissa Horizon Cloud Service – first-gen, Unified Access Gateway appliances can be deployed as part of the Horizon Cloud pod’s gateway configuration. See First-Gen Tenants - Specify the Horizon Cloud Pod’s Gateway Configuration in the First-Gen Tenants - Horizon Cloud Deployments and Onboarding Pods.

Table 2: Implementation Strategy for External Access to the Horizon Cloud Service Component

Decision

Unified Access Gateway was deployed as part of Horizon Cloud Service on Microsoft Azure.

Justification

This strategy provides external access for Workspace ONE users of the Horizon Cloud desktops and applications.

Deployment is automated when selected as part of the Horizon Cloud pod’s gateway configuration

 

Design

A successful deployment of Unified Access Gateway is dependent on good planning and a robust understanding of the platform. The following sections discuss the design options and detail the design decisions that were made to satisfy the design requirements.

Scalability

Omnissa Unified Access Gateway gives three sizing options during deployment.

Table 3: Unified Access Gateway Sizing Options

Item

Standard

Large

Extra Large

CPU (cores)

2

4

8

Memory (in GB)

4

16

32

Minimum disk size required (in GB)

20

20

20

Because multiple Workspace ONE UEM services can be enabled on a single appliance, during the design phase, consider which use cases require Workspace ONE UEM services. For example, consider the number of concurrent connections required, the desired network throughput, and how critical each one is for the business. This key information helps determine the number of appliances you will need and how to distribute services across the appliances.

As an example, in a large deployment, although all Workspace ONE UEM services might be needed, not all users will need to consume all services equally. Identifying the number of users that will consume each service is key to helping determine the number of appliances to use.

Unified Access Gateway provides the flexibility to design your deployment based on your specific business needs. You have the following options:

  1. All Workspace ONE UEM services can be enabled in each appliance.
  2. Multiple services can be enabled (any two or all three Workspace ONE UEM services) per appliance.
  3. A single service can be enabled per appliance.

Take into consideration what the business impact would be if users could not get access to an email or one of their business-critical applications through one of the services. To help mitigate this type of risk, you might choose to have all services enabled in each appliance rather than spreading different services across different sets of appliances.

Note: To satisfy high-availability requirements, the proposed solution in our reference architecture was deployed based on the best practice of using n+1 appliances. It is possible to deploy only a single Unified Access Gateway appliance as part of a smaller deployment. However, it is recommended to deploy at least two load-balanced appliances.

Table 4: Implementation Strategy for Accommodating Workspace ONE UEM Service Connections

Decision

Three large-sized Unified Access Gateway appliances were deployed to satisfy the requirement for 50,000 devices that leverage Tunnel, Content Gateway, and Web Reverse Proxy with Identity Bridging.

Secure Email Gateway was not enabled because the email infrastructure was hosted in the cloud. Instead, we used Workspace ONE Mobile Email Management using a direct model via PowerShell with Microsoft Office 365.

Justification

Each service is designed to support 50,000 sessions, which gives a total of 100,000 sessions. Two appliances satisfy the load demand and a third provides high availability (n+1).

For Horizon services, use a standard-sized appliance which will support up to 2,000 Horizon connections.

Table 5: Implementation Strategy for Accommodating Horizon Desktop and App Connections

Decision

Five standard-sized Unified Access Gateway appliances were deployed to satisfy the requirement for 8,000 concurrent external connections to Horizon desktops and applications.

Justification

Four appliances can satisfy the load demand, and a fifth provides high availability (n+1).

For detailed sizing information based on single or multiple combinations of edge services enabled on Unified Access Gateway, visit the Omnissa Configuration Maximums.

Deployment Model

Unified Access Gateway offers basic and cascade-mode architecture models for deployment. Both configurations support load-balancing for high availability and SSL/TLS offloading.

  • In the basic deployment model, Unified Access Gateway is typically deployed in the DMZ network, behind a load balancer.
  • The cascade-mode deployment model includes front-end and backend instances of the Unified Access Gateway, which have separate roles. The Unified Access Gateway front-end appliance resides in the DMZ and can be accessed from public DNS over the configured ports.

Figure 2: Example Basic and Cascade Deployment of Tunnel and Content

The Unified Access Gateway backend appliance is deployed in the internal network, which hosts internal resources. Edge services enabled on the front-end can forward valid traffic to the backend appliance after authentication is complete. The front-end appliance must have an internal DNS record that the backend appliance can resolve. This deployment model separates the publicly available appliance from the appliance that connects directly to internal resources, providing an added layer of security.

Cascade mode is supported only for the following edge services: Horizon, Tunnel, and Content Gateway.

Reasons to adopt cascade mode for Tunnel and Content Gateway edge services, are:

  • An organization might have limited or no DNS access in the DMZ, which makes it difficult to resolve the internal FQDN or host name that the edge service requires.
  • The organization’s security policies might restrict access from the DMZ directly to internal resources.

In an Omnissa Horizon deployment, cascade mode does not require a double DMZ, but for environments where a double DMZ is mandated, the front-end Unified Access Gateway appliance can act as the Web Reverse Proxy in the DMZ, and the backend appliance can have the Horizon edge service enabled.

Table 6: Deployment Mode Chosen for This Reference Architecture

Decision

Basic deployment mode was used to deploy all Unified Access Gateway appliances, which were located behind load balancers.

Justification

DNS was available in the DMZ and was able to resolve internal host names. Access to the internal network was restricted to the Unified Access Gateway backend NIC by means of firewall rules. Incoming traffic was restricted to the Internet NIC by means of load balancers.

Load Balancing 

It is strongly recommended that users connect to Unified Access Gateway using a load-balanced virtual IP (VIP). This ensures that user load is evenly distributed across all available Unified Access Gateway appliances. Using a load balancer also facilitates greater flexibility by enabling IT administrators to perform maintenance, upgrades, and configuration changes without impacting users.

High Availability

Unified Access Gateway provides, out-of-the-box, a high-availability solution for the Unified Access Gateway edge services deployed in vSphere environments. The solution supports up to 10,000 concurrent connections in a high-availability (HA) cluster and simplifies HA deployment and configuration of the services.

The HA component of Unified Access Gateway requires an administrator to specify an IPv4 virtual IP address (VIP) and a group ID. Unified Access Gateway assigns this VIP address to only one of the nodes in the cluster. If that node fails, the VIP address gets reassigned automatically to one of the other available nodes in the cluster. HA and load distribution occur among all the nodes in the cluster that share the same group ID.

A screenshot of a computer</p>
<p>Description automatically generated

Figure 3: Virtual IP Address and Group ID Configuration for HA in Two Separate Clusters

Unified Access Gateway leverages different algorithms to balance traffic and session affinity:

  • For Horizon and web reverse proxy, source IP affinity is used with a round-robin algorithm for distribution.
  • For Tunnel (Per-App Tunnel), Content Gateway, and Secure Email Gateway, there is no session affinity, and a least-connection algorithm is used for distribution.

Regarding IP address requirements, n+1 public IP addresses are required for Horizon components:

  • One IP address for the load-balanced floating VIP used for the XML-API
  • An additional one per Unified Access Gateway appliance for the secondary protocols (tunnel, Blast, PCoIP), which is the IP assigned to NIC 1 (eth0) and will not use HA

The XML-API traffic is routed to the current primary (VIP) and represents less than 1 percent of the Horizon Client traffic. The rest of the traffic goes directly from the client to the assigned Unified Access Gateway during XML-API authentication.

A screenshot of a computer</p>
<p>Description automatically generated

Figure 4: Unified Access Gateway HA Flow for Horizon Edge Services

For the Web Reverse Proxy, Per-App Tunnel, Content Gateway, and Secure Email Gateway (SEG), only a single public IP address for the VIP is required because traffic will always flow to the VIP address first and then be forwarded to the correct Unified Access Gateway appliance.

A screenshot of a computer</p>
<p>Description automatically generated

Figure 5: Unified Access Gateway HA Flow for Tunnel and Content Gateway Edge Services

For Secure Email Gateway in an HA scenario, it is important to enable SEG Clustering on the Workspace ONE UEM console. SEG Clustering ensures that all the Secure Email Gateways that are part of the cluster receive updated policies from Workspace ONE UEM in a synchronized fashion.

The SEG Cluster configuration on the Workspace ONE UEM Console requires the administrator to add all Secure Email Gateway IP address, rather than using hostnames. If you deploy Unified Access Gateway with multiple NICs, you must inform the IP address of the management NIC. SEG clustering on ports 5701 and 41232 are restricted to the management NIC.

A screenshot of a computer screen</p>
<p>Description automatically generated

Figure 6: Unified Access Gateway HA Flow for Secure Email Gateway Edge Service

Administrators can use the Unified Access Gateway administration UI to access the SEG Health Diagnostic Page, located on the Edge Service Session tab. This page displays the real-time status of the Secure Email Gateway service, including the SEG Cluster. Administrators also have the option of accessing the SEG REST API at the following URL, where <UAG-hostname> is the hostname of the appliance:

https://<UAG-hostname>:9443/rest/v1/monitor/seg/diagnostics/diagnostic

For more information on the Unified Access Gateway High Availability component and configuration of edge services in HA, see the following resources:

Unified Access Gateway continues to support third-party load balancers, for organizations who prefer this mode of deployment. For more information, see:

When deploying Unified Access Gateway on Amazon Web Services or Microsoft Azure, it is strongly recommended to leverage the native HA/load balancing solution offered by the cloud provider.

Table 7: Load-Balancing Strategy for Unified Access Gateway Appliances

Decision

An external third-party load balancer was deployed in front of the Unified Access Gateway appliances.

Justification

To meet the goals of scalability and availability, multiple Unified Access Gateway appliances are required.

Service Design

A Unified Access Gateway appliance is capable of running multiple edge services on the same appliance. In larger environments, be sure to separate Horizon traffic from Workspace ONE UEM services, and have discrete sets of Unified Access Gateway appliances for each. The Web Reverse Proxy edge service is the only exception. It can be enabled in conjunction with Horizon and Workspace ONE UEM services.

Table 8: Strategy for Separating Horizon Traffic from Workspace ONE UEM Services

Decision

Separate sets of Unified Access Gateway appliances were deployed for on-premises services. One set provided Horizon services, and a second supported Workspace ONE UEM services (Content and Tunnel).

Justification

A best practice for large deployments is to separate the network traffic and load required for Horizon from other uses.

Because multiple edge services can be enabled on the same appliance, by default each one of them runs on a separate port, which can require opening multiple ports and creating additional firewall rules. In order to avoid that situation, Unified Access Gateway introduced TLS port sharing, which allows Tunnel (Per-App Tunnel), Content Gateway, Secure Email Gateway, and Web Reverse Proxy edge services to all use TCP port 443.

For Tunnel, only the Per-App Tunnel component was used to support access to the internal web. Workspace ONE UEM provides two related solutions that are part of the Unified Access Gateway software appliance:

  • Per-App Tunnel – Enables an SSL/TLS VPN connection on a per-app basis for any public or internal application for managed devices. The Workspace ONE Tunnel application resides on a device, and an administrator explicitly specifies which apps are enabled for Tunnel. Workspace ONE also offers a new Tunnel SDK module as part of the Workspace ONE SDK, which serves as a replacement to the Tunnel Proxy solution. Generally speaking, the Per-App Tunnel solution is more secure, has better performance, and has more features than Tunnel Proxy.
  • Tunnel Proxy (obsolete) – Enables SDK-built applications to set up an app-level proxy connection to internal sites, leveraging HTTPS encryption and certificate authentication. The Workspace ONE Web app embeds proxy support by default.

All Tunnel Proxy use cases have been consolidated into the Tunnel edge service, app, and SDK. Use of Tunnel Proxy is no longer recommended.

The consolidation of all Tunnel use cases under Tunnel (Per-App Tunnel) edge service on Unified Access Gateway brings some additional benefits:

  • Reduces the number of non-standard ports opened on DMZ.
  • Enables the use of the Unified Access Gateway high availability component to load balance Tunnel traffic on port 443.
  • Enables the use of multiple edge services (Web Reverse Proxy, Content Gateway, Secure Email Gateway) on the same appliance using a single port (443).

For organizations looking to migrate from Tunnel Proxy to Per-App Tunnel, see the Migrating from Tunnel Proxy to Per-App Tunnel article on Tech Zone.

Table 9: Strategy for Using Tunnel

Decision

Only the Per-App Tunnel component was enabled as part of Tunnel edge service to support use cases on MDM and registered mode.

Justification

Tunnel Proxy is obsolete and is therefore no longer recommended. All use cases are now supported by Tunnel (Per-App Tunnel).

When sharing TCP port 443, ensure that each configured edge service has a unique external DNS entry pointing to the Unified Access Gateway external NIC IP address.

For services that do not share TCP port 443, a single DNS entry can be shared across those services.

For step-by-step instructions on how to configure each of the Unified Access Gateway edge services, see the following articles on Tech Zone:

Table 10: Strategy for Port Sharing by Edge Services

Decision

Identity bridging, Tunnel, and Content edge services were enabled on the same appliance. The services shared TCP port 443, but a unique DNS entry was created for each service. The DNS entry pointed to the load balancer, which forwarded traffic to the pool of external Unified Access Gateway IP addresses.

Justification

This strategy leverages TLS port sharing for identity bridging, Tunnel, and Content services to minimize the number of nonstandard ports and firewall rules required.

Table 11: Port Strategy for the Horizon Edge Service

Decision

The Horizon edge service was configured to use TCP port 443 to perform authentication and TCP port 8443 and UDP port 8443 to access internal desktops and RDSH-published applications using the Blast Extreme display protocol.

Justification

Best practice is to use Blast Extreme with TCP 8443 and UDP 8443, which are the defaults. When a client environment has UDP blocked, Blast Extreme still works; however, when UDP 8443 is allowed, communication is more efficient.

Network Segments

Unified Access Gateway can be deployed with one, two, or three network interface controllers (NICs). The choice is determined by your network requirements and discussions with your security teams to ensure compliance with company policy.

Single-NIC Deployment

In a single-NIC deployment, all traffic (Internet, backend, and management) uses the same network interface. Authorized traffic is then forwarded by Unified Access Gateway through the inner firewall to resources on the internal network using the same NIC. Unauthorized traffic is discarded by Unified Access Gateway.

A diagram of a network</p>
<p>Description automatically generated

Figure 7: Unified Access Gateway Single-NIC Deployment

Two-NIC Deployment

A two-NIC deployment separates the Internet traffic onto its own NIC, while the management and backend network data still share a NIC.

The first NIC still used for Internet facing unauthenticated access, but the backend authenticated traffic and management traffic are separated onto a different network. This type of deployment is suitable for production environments.

A diagram of a network</p>
<p>Description automatically generated

Figure 8: Unified Access Gateway Two-NIC Deployment

In this two-NIC deployment, traffic going to the internal network through the inner firewall must be authorized by Unified Access Gateway. Any unauthorized traffic is not allowed on this backend network. Management traffic such as the REST API for Unified Access Gateway uses only this second network.

If a device on the unauthenticated front-end network is compromised—for example, if a load balancer were compromised—then reconfiguring that device to bypass Unified Access Gateway would still not be possible in this two NIC deployment. It combines layer 4 firewall rules with layer 7 Unified Access Gateway security.

Similarly, if the Internet-facing firewall is misconfigured to allow TCP port 9443 through, the Unified Access Gateway Management REST API would still not be exposed to Internet users. A defense-in-depth principle uses multiple levels of protection, such as knowing that a single configuration mistake or system attack will not necessarily create an overall vulnerability.

In a two-NIC deployment, it is common to put additional infrastructure systems such as DNS servers, RSA SecurID Authentication Manager servers, and so on in the backend network within the DMZ so that they are not visible from the Internet-facing network. This guards against layer-2 attacks from a compromised front-end system on the Internet-facing LAN and thereby effectively reduces the overall attack surface.

When the Horizon service is enabled on Unified Access Gateway, most network traffic is the display protocol traffic for Blast Extreme and PCoIP. With a single NIC, display protocol traffic to or from the Internet is combined with traffic to or from the backend systems. When two or more NICs are used, the traffic is spread across front-end and backend NICs and networks. This can result in performance benefits by reducing the potential bottleneck of a single NIC.

Three-NIC Deployment

A three-NIC deployment separates the Internet traffic onto its own NIC, and separates management and backend network data onto dedicated networks. HTTPS management traffic to port 9443 is then only possible from the management LAN. This type of deployment is suitable for production environments.

Figure 9: Unified Access Gateway Three-NIC Deployment

Table 12: Strategy for Separating Front-End, Backend, and Management Traffic

Decision

Unified Access Gateway appliances were deployed in a dual-NIC mode.

Justification

This strategy meets the requirements of separating Internet traffic from management and backend data.

Authentication

Unified Access Gateway supports multiple authentication options, for example, pass-through, RSA SecurID, RADIUS, SAML, and certificates, including smart cards. Pass-through authentication forwards the request to the internal server or resource. Other authentication types enable authentication at the Unified Access Gateway, before passing authenticated traffic through to the internal resource.

These options are depicted in the following diagrams.

A screenshot of a computer</p>
<p>Description automatically generated

Figure 10: Unified Access Gateway Pass-Through Authentication

A screenshot of a computer</p>
<p>Description automatically generated

Figure 11: Unified Access Gateway Two-Factor Authentication

Starting with Unified Access Gateway 3.8, administrators can now extend the use of SAML to authenticate Horizon users against third-party identity providers (IdP), leveraging Unified Access Gateway as the service provider (SP). This new capability requires Horizon Connection Server 7.11 or later, and user authentication must go through Unified Access Gateway.

The authentication sequence can be configured as SAML and Passthrough or just SAML:

  • When Auth Methods is set to SAML and Passthrough, the SAML assertion is validated by Unified Access Gateway. The Horizon Connection Server authenticates the user against Active Directory when launching remote desktops and applications.
  • When Auth Methods is set to SAML, the SAML assertion is validated by Unified Access Gateway and is passed to the backend. The True SSO feature can allow users to single-sign-on to their remote desktops and applications.

With both authentication methods, users are redirected to the Identity Provider for SAML authentication. Service provider (SP) and IdP initiated flows are supported.

A screenshot of a computer</p>
<p>Description automatically generated

Figure 12: Unified Access Gateway SAML Authentication

For general information and configuration of SAML and Unified Access Gateway support for Horizon, see Configuring Horizon for Unified Access Gateway and Third-Party Identity Provider Integration.

For detailed information and step-by-step guidance on how to integrate Okta and Unified Access Gateway for Horizon authentication, see the Tech Zone Operational Tutorial Enabling SAML 2.0 Authentication for Horizon with Unified Access Gateway and Okta.

In addition to the current authentication methods available, you can use services such as Tunnel and Workspace ONE Access to provide an additional layer of authentication. These authentication mechanisms come into play based on device certificate, device compliance, or both. Certificate and compliance checks are performed when the device traffic arrives at the Unified Access Gateway. At that point, the edge services communicate with Workspace ONE UEM through APIs.

For guidance on how to set up authentication on DMZ, see Configuring Authentication in DMZ.

Table 13: Type of Authentication Chosen for This Reference Architecture

Decision

Pass-through authentication was configured.

Justification

Users can authenticate through Workspace ONE and Workspace ONE Access. Having authentication performed by Unified Access Gateway would force users to authenticate to resources a second time.

Deployment Methods

In this section, we briefly discuss the two supported methods of deploying Unified Access Gateway and then detail the optimal solution to satisfy the design requirements.

  • PowerShell script – The PowerShell method ensures that the Unified Access Gateway virtual appliance is production ready on first boot. The IT administrator updates an INI file with the required configuration settings and then deploys the Unified Access Gateway by entering a simple deployment command in PowerShell (.\uagdeploy.ps1 .\<name>.ini) .
    • For deployments on VMware vSphere, this method uses the VMware OVF Tool command-line utility in the background.
    • For deployments on Microsoft Azure, Hyper-V, and Amazon Web Services (AWS), the OVF tool is not required because Unified Access Gateway leverages the PowerShell module for the respective hypervisor.
  • VMware vSphere OVF template and administration console – With this option, you run the Import OVF (Open Virtualization Format) wizard and respond to various deployment questions. This method requires responses from an IT administrator during deployment. If you use this method, the Unified Access Gateway is not production ready on first boot and requires post-deployment configuration using the administration console. The required configuration tasks can be performed either manually or by importing a configuration file from another Unified Access Gateway appliance.

Table 14: Strategy for Deploying and Configuring Unified Access Gateway Appliances

Decision

The PowerShell method for deployment was used.

Justification

This option does not require the IT administrator to manually enter settings during deployment and so is less prone to input error.

This option also makes upgrading and deploying additional appliances easier.

More information on using the PowerShell method at Using PowerShell to Deploy Unified Access Gateway. The PowerShell script and sample INI files can be downloaded from the Unified Access Gateway product download page. For step-by-step instructions on how to deploy Unified Access Gateway, see the following articles on Tech Zone:

For deployment of Unified Access Gateway on vSphere and configuration of any of the edge services through PowerShell, see the Deploy section of the Tech Zone Unified Access Gateway product page.

Required Deployment Information

Before deploying a Unified Access Gateway appliance, you must verify that certain prerequisites are met and provide the following information.

Certificates

TLS/SSL certificates are used to secure communications for the user between the endpoint and the Unified Access Gateway and between the Unified Access Gateway and internal resources. Although Unified Access Gateway generates default self-signed certificates during deployment, for production use, you should replace the default certificates with certificates that have been signed by a trusted certificate authority (CA-signed certificates).

You can replace certificates either during deployment or as part of the initial configuration. The same certificate or separate certificates can be used for the user and the administrative interfaces, as desired.

The default certificates generated by Unified Access Gateway apply only to the administrative UI, Horizon, and Web Reverse Proxy edge service. For more information, see the Certificates section of Deploying Unified Access Gateway.

For the Workspace ONE UEM edge services, self-signed certificates are generated by the AirWatch CA through the Workspace ONE UEM console. These can also be configured to use public third-party certificates.

The following types of certificates are supported:

  • Single-server-name certificates, which means using a unique server certificate for each Unified Access Gateway appliance
  • Subject alternate name (SAN) certificates
  • Wildcard certificates

Certificate files can be provided in either PFX or PEM format.

For guidance on how to configure and update Unified Access Gateway to use TLS/SSL for the administrative UI, Horizon, and Web Reverse Proxy edge services, see TLS/SSL certificates and Update TLS Server Signed Certificates.

For guidance on how to configure and update Unified Access Gateway to use TLS/SSL for Workspace ONE UEM Edge Service, see:

Security protocols and cipher suites are configured on a per-service basis on Unified Access Gateway. Administrators can update the security protocols and cipher suites any time after deployment using the Unified Access Gateway administration console or REST API. For more information see Security Protocols and Cipher Suites.

Passwords

Unified Access Gateway requires the IT administrator to define two passwords during installation: The first secures access to the REST API, and the second secures access to the Unified Access Gateway appliance console. The passwords must meet the minimum requirements documented Modify User Account Setting.

Users with administrator privileges can reset their password through the Unified Access Gateway admin UI. However, If the admin user password is forgotten, the user can log in to the Unified Access Gateway console (command line) using the root user credentials and reset the admin UI password. For more information, see Reset the Admin Password using the Unified Access Gateway Console.

IP Address and Fully Qualified Domain Name (FQDN)

As previously discussed, the Unified Access Gateway in this scenario is configured with two NICs:

  • Internet-facing IP address and external FQDN
  • Backend and management IP address and FQDN

Summary and Additional Resources

Now that you have come to the end of this design chapter on Omnissa Horizon Cloud Service ­– next-gen, you can return to the reference architecture landing page and use the tabs, search, or scroll to select further chapter in one of the following sections:

  • Overview chapters provide understanding of business drivers, use cases, and service definitions.
  • Architecture chapters give design guidance on the Omnissa products you are interested in including in your deployment, including Workspace ONE UEM, Access, Intelligence, Workspace ONE Assist, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
  • Integration chapters cover the integration of products, components, and services you need to create the environment capable of delivering the services that you want to deliver to your users.
  • Configuration chapters provide reference for specific tasks as you deploy your environment, such as installation, deployment, and configuration processes for Omnissa Workspace ONE, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Management, and more.

Additional Resources

For more information about Unified Access Gateway, you can explore the following resources:

Changelog

The following updates were made to this guide:

Date

Description of Changes

2024-10-11

  • Updated graphics and diagrams.

2024-05-15

  • Updated for Omnissa docs, KB, and Tech Zone links.

2023-07-24

  • Added this Summary and Additional Resources section to list changelog, authors, and contributors within each design chapter.

2020-07-01

  • Updated sizing guidance.
  • Updated recommendation to use Per-App Tunnel instead of Tunnel Proxy.

2020-02-27

  • Added support for Secure Email Gateway (SEG).
  • Added new sizing XL option for SEG.

Author and Contributors

This chapter was written by:

Feedback

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.


Associated Content

home-carousel-icon From the action bar MORE button.

Filter Tags

Horizon Workspace ONE Unified Access Gateway Document Reference Architecture Advanced Design Secure Remote Access