To enable use of two-factor authentication in the gateway settings of an already deployed pod, use the Edit action in the pod's details page. Gateway configurations on your pod use Unified Access Gateway VMs and are configured to provide your end users' access to their desktops and applications. You can add these two-factor authentication settings to the pod's existing gateway configurations, or you can add them at the same time that you add a new gateway configuration. You use the Edit Pod workflow to add the two-factor authentication settings to the pod's gateway configuration.

Note: When the tenant is configured to use Universal Broker and the broker settings have two-factor authentication enabled, the same two-factor authentication type must be set on the external gateways of all the pods in the fleet. In this scenario, when you perform these steps to add two-factor authentication to an external gateway, the user interface will enforce the choice of the two-factor authentication type that matches the one set in the broker settings.

Prerequisites

For the gateway on which you are adding two-factor authentication, verify that you have completed the fields for that gateway configuration in the wizard. When configuring two-factor authentication to an on-premises authentication server, you also provide information in the following fields so that the Unified Access Gateway instances for that gateway can resolve routing to that on-premises server.

Option Description
DNS Addresses Specify one or more addresses of DNS servers that can resolve the name of your on-premises authentication server.
Routes Specify one or more custom routes that allow the pod's Unified Access Gateway instances to resolve network routing to your on-premises authentication server.

For example, if you have an on-premises RADIUS server that uses 10.10.60.20 as its IP address, you would use 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.

Verify that you have the following information used in your authentication server's configuration, so that you can provide it in the appropriate fields in the pod deployment wizard. If you are using a RADIUS authentication server and have both a primary and secondary server, obtain the information for each of them.

RADIUS

If you are configuring settings for both a primary and auxiliary RADIUS server, obtain the information for each of them.

  • IP address or DNS name of the authentication server
  • The shared secret that is used for encryption and decryption in the authentication server's protocol messages
  • Authentication port numbers, typically 1812/UDP for RADIUS.
  • Authentication protocol type. The authentication types include PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), MSCHAP1, MSCHAP2 (Microsoft Challenge Handshake Authentication Protocol, version 1 and 2).
    Note: Check your RADIUS vendor's documentation for the authentication protocol that your RADIUS vendor recommends and follow their indicated protocol type. The pod's capability to support two-factor authentication with RADIUS is provided by the Unified Access Gateway instances, and Unified Access Gateway supports PAP, CHAP, MSCHAP1, and MSCHAP2. PAP is generally less secure than MSCHAP2. PAP is also a simpler protocol than MSCHAP2. As a result, even though most RADIUS vendors are compatible with the simpler PAP protocol, some RADIUS vendors are not as compatible with the more secure MSCHAP2.
RSA SecurID
Note: The RSA SecurID type is supported with Horizon Cloud on Microsoft Azure deployments that are running manifest 3139.x or later. The UI option to specify the RSA SecurID type in the Add Pod and Edit Pod wizards will become visible to select in the wizards starting in mid-March 2022.
  • Access key from the RSA SecurID authentication manager server.
  • RSA SecurID communication port number. Typically 5555, as set in the RSA Authentication Manager system settings for RSA SecurID Authentication API.
  • Host name of the RSA SecurID authentication manager server.
  • IP address of that RSA SecurID authentication manager server.
  • If the RSA SecurID authentication manager server or its load balancer server has a self-signed certificate, you will need the CA certificate to provide in the Add Pod wizard. The certificate should be in PEM format (file types .cer or .cert or .pem)

Procedure

  1. If the Edit Pod window's Gateway Settings step is not already open, click Edit in the pod's details page and then click Next to move to the Gateway Settings step.
  2. Position the window at the gateway type for which you want to enable two-factor authentication, either external or internal.
  3. Switch on the Enable two-factor authentication toggle.
    When the toggle is enabled, the wizard displays the additional configuration fields. Use the scroll bar to access all of the fields.

    The following screenshot is an example of what is displayed after you switch on the toggle in the External UAG section.

    Horizon Cloud on Microsoft Azure: Pod deployment wizard's two-factor authentication fields in their initial state after enabling the toggle to enable two-factor authentication.
  4. Select your two-factor authentication type, Radius or RSA SecurID.
    Currently, the available, supported types are RADIUS and RSA SecurID.

    After selecting the type, the Two-factor Authentication Configuration menu automatically reflects that you are adding a configuration of that selected type. For example, if RSA SecurID type is selected, the Two-factor Authentication Configuration menu displays New RSA SecurID.

  5. In the Configuration Name field, enter an identifying name for this configuration.
  6. In the Properties section, specify details related to the end users' interaction with the login screen they will use to authenticate for access.

    The wizard displays fields based on the configuration that a Horizon Cloud on Microsoft Azure deployment supports using with its gateway configurations. The fields vary according to the selected two-factor authentication type. Refer to the table below that corresponds to your selected type, RADIUS or RSA SecurID.

    RADIUS

    As you complete the fields, specifying details about the primary authentication server is required. If you have a secondary authentication server, enable the Auxiliary Server toggle and specify the details for that server also.

    Option Description
    Display Name You can leave this field blank. Even though this field is visible in the wizard, it only sets an internal name in the Unified Access Gateway configuration. This name is not used by Horizon clients.
    Display Hint Optionally enter a text string that will be displayed to the end users in the message on the end-user client login screen when it prompts the user for their RADIUS user name and passcode. The specified hint appears to the end user as Enter your DisplayHint user name and passcode, where DisplayHint is the text you specify in this field.

    This hint can help guide users to enter the correct RADIUS passcode. As an example, specifying a phrase like Example Company user name and domain password below for would result in a prompt to the end user that says Enter your Example Company user name and domain password below for user name and passcode.

    Name ID Suffix This setting is used in SAML scenarios, where your pod is configured to use TrueSSO for single sign-on. Optionally provide a string which will be appended to the SAML assertion user name that is sent in the request to the pod manager. For example, if the user name is entered as user1 on the login screen and a name ID suffix of @example.com was specified here, a SAML assertion user name of user1@example.com is sent in the request.
    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 Enable this toggle to maintain the user's Active Directory username during the authentication flow that transpires among the client, the Unified Access Gateway instance, and the RADIUS service. When enabled:
    • The user must have the same username credentials for RADIUS as for their Active Directory authentication.
    • The user cannot change the username in the login screen.

    If this toggle is switched off, the user is able to type a different user name in the login screen.

    Note: For the relationship between enabling Maintain Username and the domain security settings in Horizon Cloud, see the Domain Security Settings on General Settings Page topic.
    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.
    RSA SecurID
    Option Description
    Access Key Type in the access key for your RSA SecurID system, obtained in the system's RSA SecurID Authentication API settings.
    Server Port Specify the value configured in your system's RSA SecurID Authentication API settings for the communication port, typically 5555 by default.
    Server Host Name Enter the DNS name of the authentication server.
    Server IP Address Enter the IP address of the authentication server.
    Number of Iterations Enter the maximum number of failed authentication attempts that a user is allowed before they are locked out for one hour. The default is five (5) attempts.
    CA Certificate This item is required when your RSA SecurID Authentication Manager server or its load balancer uses a self-signed certificate. In this case, copy the CA certificate and paste it into this field. As described above in this page, the certificate information should be provided in PEM format.

    When the server has a certificate signed by a public Certificate Authority (CA), this field is optional.

    Authentication Timeout Specify the number of seconds you want the authentication attempt to be available between the Unified Access Gateway instances and the RSA SecurID authentication server before timing out. The default value is 180 seconds.
  7. When you have made all the settings you want, 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 new configuration to the pod, the pod summary page's section for the gateway on which you added two-factor authentication will show the Pending status.

When the workflow is completed, the status will show as Ready and the gateway's two-authentication settings 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

Important: Before your end users can start using the gateway with the two-factor authentication feature, you must complete the following tasks.
  • If the pod's external gateway has two-factor authentication configured and the two-factor authentication server is not reachable within the same VNet topology into which the gateway's Unified Access Gateway instances are deployed, configure that two-factor authentication server to allow communication from the IP address of the external gateway's load balancer.

    In this scenario where the two-factor authentication server is not reachable within the same VNet topology as the gateway deployment, the Unified Access Gateway instances attempt contact with that server using that load balancer address. To allow that communication traffic, ensure the load balancer resource's IP address that is in that external gateway's resource group is specified as a client or a registered agent in your two-factor authentication server's configuration. Refer to the documentation for your two-factor authentication server for the specifics on how to allow that communication.

  • If your two-factor authentication server is reachable within the same VNet topology, configure the two-factor authentication server to allow communication from the appropriate NICs that were created for the deployment's Unified Access Gateway instances in Microsoft Azure.

    Your network administrator determines the two-factor authentication server's network visibility to the Azure VNet topology and its subnets used for the deployment. The two-factor authentication server must allow communication from the IP addresses of the Unified Access Gateway instances' NICs that correspond to the subnet for which your network administrator has given network visibility to the two-factor authentication server.

    The gateway's resource group in Microsoft Azure has four NICs that correspond to that subnet, two that are currently active for the two Unified Access Gateway instances and two that are idle and will become the active ones after the pod and its gateways go through an update.

    To support communication traffic between the gateway and the two-factor authentication server both for ongoing pod operations and after each pod update, ensure the IP addresses of those four NICs are specified as clients or as registered agents in that server's configuration. Refer to the documentation for your two-factor authentication server for the specifics on how to allow that communication.

For information on how to obtain those IP addresses, see Update Your Two-Factor Authentication System with the Required Horizon Cloud Pod Gateway Information.