You can use the Edit Pod workflow to change the two-factor authentication settings on the pod's gateways, or deactivate the two-factor authentication entirely. When you change the settings, you basically type a new name for the set of two-factor authentication settings, enter the new settings you want, make sure that new name is selected for the specific gateway, and save. You use the Edit Pod workflow to change the two-factor authentication settings.

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

If you are keeping two-factor authentication enabled for one of the gateways but are changing the specific settings, verify that you have the following information:

  • When the two-factor authentication server is on-premises, verify that you have the relevant information for the following fields so that the Unified Access Gateway instances for that gateway can resolve routing to that 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. Open the Edit Pod window from the pod's details page by clicking Edit.
  2. In the Edit Pod window, click Next to move to the Gateway Settings step.
    This step has a section for the external gateway configuration and a section for the internal gateway configuration. The user interface reflects the pod's current configuration and the gateway settings it already has.
  3. Position the window at the gateway type for which you want to change the two-factor authentication, either external or internal.
  4. To deactivate two-factor authentication on the gateway, switch off the Enable two-factor authentication toggle and then go to Step 8 to save the changes.
    If the other gateway also has two-factor authentication enabled and you want to deactivate it, switch off the toggle in the section for that other gateway.
  5. To change the specific two-factor authentication settings that are set on the gateway, continue with the following steps.
    You create a new name for the new set of two-factor authentication values and save the configuration with that new name selected for that gateway section in the window.
  6. In the Configuration Name field, enter an identifying name for this configuration.
  7. 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.
  8. 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.
  9. 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: When you change the values of a gateway's two-factor authentication settings to new ones, before your end users resume using the gateway that has the new two-factor authentication values, 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, verify that the two-factor authentication server that you specified in the gateway configuration allows communications 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 an allowed client or as 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, verify that the two-factor authentication server is configured 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 allowed 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.