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.
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 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.
- Open the Edit Pod window from the pod's details page by clicking Edit.
- 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.
- Position the window at the gateway type for which you want to change the two-factor authentication, either external or internal.
- To deactivate two-factor authentication on the gateway, switch off the Enable 2 Factor Authentication toggle and then go to Step 10 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.
- 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.
- In the Name field, enter an identifying name for this configuration.
- 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
user1on the login screen and a name ID suffix of
@example.comwas specified here, a SAML assertion user name of
email@example.com 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 Dirctory 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.
- 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
user1on the login screen and a realm prefix of
DOMAIN-A\was specified here, the system sends
DOMAIN-A\user1to 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
user1on the login screen and a realm suffix of
@example.comwas specified here, the system sends
firstname.lastname@example.org the authentication server.
- (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.
- 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.
- Click Yes to start the workflow.
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.
What to do next
- 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 that the RADIUS server that you specified in the gateway configuration allows 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, verify that the RADIUS server is configured to allow connections from the appropriate NICs that were created in the gateway's resource group in Microsoft Azure. 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.