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.

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 of 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 have both a primary and secondary 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 the 1812 UDP port.
  • 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.

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 2 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 RADIUS authentication fields
  4. Select your two-factor authentication method in the drop-down list.
    In this release, RADIUS authentication is supported.
  5. In the 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.
    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 Unified Access Gateway. 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 RADIUS username during authentication to Horizon Cloud. When enabled:
    • 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 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.
  7. 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.
  8. (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. Enable the Auxiliary Server toggle and complete the fields as described in Primary Server section.
  9. 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.
  10. 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 you configured an external gateway with RADIUS settings and that RADIUS server is not reachable within the same VNet as used by the pod, or within the peered VNet topology if you deployed the external gateway into its own VNet, verify, configure that RADIUS server to allow client connections from the IP address of the external gateway's load balancer. In an external gateway configuration, the Unified Access Gateway instances attempt contact with the RADIUS server using that load balancer address. To allow the connections, ensure the load balancer resource's IP address that is in that external gateway's resource group is specified as a client in your RADIUS server configuration.
  • If you configured an internal gateway, or an external gateway and your RADIUS server is reachable within the same VNet as used by the pod, configure the RADIUS server to allow connections from the appropriate NICs that were created in the gateway's resource group in Microsoft Azure that must communicate with the RADIUS server. Your network administrator determines the RADIUS server's network visibility to the pod's Azure Virtual Network and subnets. Your RADIUS server must allow client connections from the IP addresses of those gateway NICs that correspond to the subnet for which your network administrator has given network visibility to the RADIUS 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 goes through an update. To support connectivity between the gateway and the RADIUS server both for ongoing pod operations and after each pod update, ensure the IP addresses of those four NICs are specified as clients in the RADIUS server configuration.

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