When you initially deployed a Horizon Cloud pod into Microsoft Azure without either Unified Access Gateway configuration types, or with only one type, you can add a Unified Access Gateway configuration to the pod using the Administration Console's Edit Pod wizard. You launch that wizard from the pod's summary page.

As described in Introduction to Horizon Cloud Pods in Microsoft Azure, a pod can have an external Unified Access Gateway configuration or an internal one or both. You can use this workflow to add the type that the pod does not already have. You can also specify two-factor authentication settings for the Unified Access Gateway configuration that you are adding to the pod.

Important: When modifying the pod using these steps, keep in mind the following points:
  • If an existing Unified Access Gateway configuration on the pod is not already configured with two-factor authentication, you cannot use this workflow to add the two-factor authentication settings to that existing Unified Access Gateway configuration. This release does not support adding the two-factor authentication configuration to Unified Access Gateway instances after those instances are already deployed.
  • During the time the system is changing the pod's configuration until it is finished, the following limitations apply:
    • You cannot perform administration tasks on the pod.
    • End users who do not have connected sessions to their desktops or remote applications served by the pod and who attempt to connect cannot do so.
    • End users who have connected sessions served by the pod will have those active sessions disconnected. No data loss will occur. After the configuration changes are complete, those users can reconnect.

Prerequisites

To complete the fields in the Edit Pod wizard, you must provide the information as described in Prerequisites When Deploying With a Unified Access Gateway Configuration. If you are also specifying two-factor authentication settings for the configuration you are adding, you must provide the information described in Prerequisites When Deploying With a Two-Factor Authentication Configuration.

Important: All certificates in the certificate chain must have valid time frames. The Unified Access Gateway VMs require that all of the certificates in the chain, including any intermediate certificates, have valid time frames. If any certificate in the chain is expired, unexpected failures can occur later as the certificate is uploaded to the Unified Access Gateway configuration.

Procedure

  1. In the Administration Console, navigate to Settings > Capacity and click the pod's name to open its details page.
  2. In the pod's details page, click Edit.
  3. In the Edit Pod window, click Next to move to the Gateway Settings step.
  4. If you are adding the external configuration to a pod that does not have it, set the Enable External UAG? toggle to Yes and complete the fields in the External UAG section.
    Option Description
    Enable External UAG? When Yes is selected, access to desktops and applications is enabled for users located outside of your corporate network. The pod includes a Microsoft Azure public load balancer and Unified Access Gateway instances to enable this access.
    Note: Leaving the default Yes setting is recommended.

    When set to No, clients must either connect directly to the pod and not through Unified Access Gateway, or they connect through an internal Unified Access Gateway configuration. In the case of clients connecting directly to the pod and not through Unified Access Gateway, some post-deployment steps are required. In this case, after the pod is deployed, follow the steps in Upload SSL Certificates to a Horizon Cloud Pod for Direct Connections.

    FQDN Enter the required fully qualified domain name (FQDN), such as ourOrg.example.com, which your end users will use to access the service. You must own that domain name and have a certificate in PEM format that can validate that FQDN.
    Important: This FQDN cannot contain underscores. In this release, connections to the Unified Access Gateway instances will fail when the FQDN contains underscores.
    DMZ Subnet

    DMZ Subnet (CIDR)

    When Use Existing Subnet is set to Yes in the preceding wizard step, DMZ Subnet lists the subnets available on the VNet selected for Virtual Network. Select the existing subnet that you want to use for the pod's DMZ subnet.
    Important: Select an empty subnet, one that has no other resources attached to it. If the subnet is not empty, unexpected results might occur during the deployment process or pod operations.

    When Use Existing Subnet is set to No in the preceding wizard step, enter the subnet (in CIDR notation) for the DMZ (demilitarized zone) network that will be configured to connect the Unified Access Gateway instances to the deployed public load balancer.

    DNS Addresses Optionally enter addresses for additional DNS servers that Unified Access Gateway can use for name resolution, separated by commas. When configuring this external Unified Access Gateway configuration to use two-factor authentication with your on-premises RADIUS server, you would specify the address of a DNS server that can resolve the name of your on-premises RADIUS server.

    As described in the deployment prerequisites, a DNS server must be set up internally in your subscription and configured to provide external name resolution. The Unified Access Gateway instances use that DNS server by default. If you specify addresses in this field, the deployed Unified Access Gateway instances use the addresses in addition to the prerequisite DNS server that you configured in your subscription's virtual network.

    Routes Optionally specify custom routes to additional gateways that you want the deployed Unified Access Gateway instances to use to resolve network routing for the end user access. The specified routes are used to allow Unified Access Gateway to resolve network routing such as to RADIUS servers for two-factor authentication.

    When configuring this pod to use two-factor authentication with an on-premises RADIUS server, you must enter the correct route the Unified Access Gateway instances can use to reach the RADIUS server. For example, if your on-premises RADIUS server uses 10.10.60.20 as its IP address, you would enter 10.10.60.0/24 and your default route gateway address as a custom route. You obtain your default route gateway address from the Express Route or VPN configuration you are using for this environment.

    Specify the custom routes as a comma-separated list in the form ipv4-network-address/bits ipv4-gateway-address, for example: 192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2.

    Certificate Upload the certificate in PEM format that Unified Access Gateway will use to allow clients to trust connections to the Unified Access Gateway instances running in Microsoft Azure. The certificate must be based on the FQDN you entered and be signed by a trusted CA. The PEM file must contain the entire certificate chain and the private key: SSL certificate intermediate certificates, root CA certificate, private key.
  5. If you are adding the internal configuration to a pod that does not have it, set the Enable Internal UAG? toggle to Yes and complete the fields in the Internal UAG section.
    Option Description
    Enable Internal UAG? When Yes is selected, trusted access to desktops and applications is enabled for HTML Access (Blast) connections for users located inside of your corporate network. The pod includes a Microsoft Azure internal load balancer and Unified Access Gateway instances to enable this access.
    FQDN Enter the required fully qualified domain name (FQDN), such as ourOrg.example.com, which your end users will use to access the service. You must own that domain name and have a certificate in PEM format that can validate that FQDN.
    Important: This FQDN cannot contain underscores. In this release, connections to the Unified Access Gateway instances will fail when the FQDN contains underscores.
    DNS Addresses Optionally enter addresses for additional DNS servers that Unified Access Gateway can use for name resolution, separated by commas. When configuring this internal Unified Access Gateway configuration to use two-factor authentication with your on-premises RADIUS server, you would specify the address of a DNS server that can resolve the name of your on-premises RADIUS server.

    As described in the deployment prerequisites, a DNS server must be set up internally in your subscription and configured to provide name resolution. The Unified Access Gateway instances use that DNS server by default. If you specify addresses in this field, the deployed Unified Access Gateway instances use the addresses in addition to the prerequisite DNS server that you configured in your subscription's virtual network.

    Routes Optionally specify custom routes to additional gateways that you want the deployed Unified Access Gateway instances to use to resolve network routing for the end user access. The specified routes are used to allow Unified Access Gateway to resolve network routing such as to RADIUS servers for two-factor authentication.

    When configuring this pod to use two-factor authentication with an on-premises RADIUS server, you must enter the correct route the Unified Access Gateway instances can use to reach the RADIUS server. For example, if your on-premises RADIUS server uses 10.10.60.20 as its IP address, you would enter 10.10.60.0/24 and your default route gateway address as a custom route. You obtain your default route gateway address from the Express Route or VPN configuration you are using for this environment.

    Specify the custom routes as a comma-separated list in the form ipv4-network-address/bits ipv4-gateway-address, for example: 192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2.

    Certificate Upload the certificate in PEM format that Unified Access Gateway will use to allow clients to trust connections to the Unified Access Gateway instances running in Microsoft Azure. The certificate must be based on the FQDN you entered and be signed by a trusted CA. The PEM file must contain the entire certificate chain and the private key: SSL certificate intermediate certificates, root CA certificate, private key.
  6. In the section for whichever Unified Access Gateway configuration fields you completed in the previous steps, optionally configure the end users' desktops to use RADIUS two-factor authentication by using the following steps.
    1. Select Yes for the Enable 2 Factor Authentication? toggle.
      When the toggle is set to Yes, the wizard displays the additional configuration fields. Use the scroll bar to access all of the fields.
    2. Select your two-factor authentication method in the drop-down list.
      In this release, RADIUS authentication is supported.
    3. In the Name field, enter an identifying name for this configuration.
    4. In the Properties section, specify details related to the end users' interaction with the login screen they will use to authenticate for access.
      Option Description
      Display Name Optionally provide a name that the system will display to the end users on the Horizon Cloud login screen to identify which RADIUS system they are using to authenticate for access.
      Display Hint Optionally enter a text string that the system will display in the message on the login screen to direct users to enter the correct RADIUS passcode.
      Name ID Suffix

      Even though this field is visible, it is not used in this release.

      Number of Iterations Enter the maximum number of failed authentication attempts that a user is allowed when attempting to log in using this RADIUS system.
      Maintain Username Select Yes to maintain the user's RADIUS username during authentication to Horizon Cloud. When Yes is selected:
      • The user must have the same username credentials for RADIUS as for their Active Directory authentication to Horizon Cloud.
      • The user cannot change the username in the login screen.

      If you select No, the user is able to type a different user name in the login screen.

    5. In the Primary Server section, specify details about the authentication server.
      Option Description
      Host Name / IP Address Enter the DNS name or the IP address of the authentication server.
      Shared Secret Enter the secret for communicating with the authentication server. The value must be identical to the server-configured value.
      Authentication Port Specify the UDP port configured on the authentication server for sending or receiving authentication traffic. The default is 1812.
      Accounting Port Optionally specify the UDP port configured on the authentication server for sending or receiving accounting traffic. The default is 1813.
      Mechanism Select the authentication protocol that is supported by the specified authentication server and which you want the deployed pod to use.
      Server Timeout Specify the number of seconds that the pod should wait for a response from the authentication server. After this number of seconds, a retry is sent if the server does not respond.
      Max Number of Retries Specify the maximum number of times the pod should retry failed requests to the authentication server.
      Realm Prefix Optionally provide a string which the system will place at the beginning of the user name when the name is sent to the authentication server. The user account location is called the realm.

      For example, if the user name is entered as user1 on the login screen and a realm prefix of DOMAIN-A\ was specified here, the system sends DOMAIN-A\user1 to the authentication server. If you do not specify a realm prefix, only the entered user name is sent.

      Realm Suffix Optionally provide a string which the system will append to the user name when the name is sent to the authentication server. For example, if the user name is entered as user1 on the login screen and a realm suffix of @example.com was specified here, the system sends user1@example.com to the authentication server.
    6. (Optional) In the Secondary Server section, optionally specify details about an auxiliary authentication server.
      You can configure a secondary authentication server to provide for high availability. Set the Auxiliary Server toggle to Yes and complete the fields as described for the Primary Server section.
  7. Click Save & Exit.
    A confirmation message appears asking you to confirm the start of the workflow.
  8. Click Yes to start the workflow.

Results

Until the system is finished deploying the elements for the configuration you added, the pod summary page's section for that configuration type shows Pending status.

When the workflow is completed, the status will show as Ready and the load balancer FQDN will be displayed in the page.

Note: When running this workflow for a pod in Microsoft Azure China, the process can take longer than an hour to complete. The process is subject to geographic network issues that can cause slow download speeds as the binaries are downloaded from the cloud control plane.

What to do next

For the newly added Unified Access Gateway configuration, ensure you have a CNAME record in your DNS server to map the configuration's deployed load balancer to the FQDN that you entered in the deployment wizard. See Obtain the Pod's Load Balancer Information to Map in your DNS Server for details.

If you specified RADIUS two-factor authentication for the configuration you added, you must configure your RADIUS system with the IP address of the added configuration's load balancer as a client allowed to make requests of that RADIUS system. The Unified Access Gateway instances authenticate requests from the RADIUS system through that address.