After you configure two-factor authentication settings in a Horizon Cloud pod's gateway configuration, you must also configure the corresponding two-factor authentication system's configuration to allow authentication requests communicated to it from specific gateway-related IP addresses.

The gateway's Unified Access Gateway instances will attempt to communicate with your two-factor authentication server from specific IP addresses. Your network administrator determines the two-factor authentication server's network visibility to the pod's Azure Virtual Network (VNet) and subnets. The combination of that network visibility and the pod gateway type, external or internal, determines the specific gateway-related IP addresses that you must configure in your two-factor authentication server configuration to allow it to accept that communication.

Important:

You must follow the documentation that is appropriate for your two-factor authentication system.

A RADIUS two-factor authentication system uses the concept of allowed RADIUS clients. As an example, as described in the FreeRADIUS wiki for FreeRADIUS client configuration, the /etc/raddb/clients.conf file contains the definitions of RADIUS clients as:
client NAME {
  ipaddr = IPADDRESS
  secret = SECRET
}

An RSA SecurID two-factor authentication system uses the concept of authentication agents that are registered to communicate with RSA Authentication Manager. As an example, as described in SecurID Authentication Manager Documentation - Add an Authentication Agent, you use the RSA Authentication Manager's Security Console to add the necessary IP addresses to its internal database.

This topic describes the information from your Horizon Cloud pod that you must use in your two-factor authentication server to enable communication between the pod's gateway and also to maintain resiliency of that communication after each pod update.

To accept communication from the gateway configuration's Unified Access Gateway instances, two-factor authentication servers need to allow communications from the appropriate IP addresses.

Usually your network administrator determines what network access the two-factor authentication server has to the VNet and the subnets that are connected to the deployed pod. The specific source IPs that the Unified Access Gateway instances use when contacting the two-factor authentication server depend on:

  • Whether you configured a RADIUS or RSA SecurID type on the gateway configuration.
  • Whether the gateway configuration is internal or external
  • Whether your network administrator has configured the two-factor authentication server as accessible from inside the pod's VNet, or is located outside the VNet
  • If the two-factor authentication server is accessible within the pod's VNet, from which of the pod's subnets in that VNet has your network administrator configured access to the two-factor authentication server
RSA SecurID - Both external and internal gateway configurations
The RSA Authentication Manager server will see communication from the NICS on the individual Unified Access Gateway instances. In the RSA Authentication Manager configuration, register the following NIC IP addresses as authentication agents:
  • For an external gateway, the four NICs on the gateway's dmz subnet
  • For an internal gateway, the four NICs on the gateway's tenant subnet.
RADIUS - Internal gateway configuration
The Unified Access Gateway instances deployed for an internal gateway configuration use their NICs' private IP addresses to contact that two-factor authentication server. The two-factor authentication server sees the requests coming from source IP addresses that are the NICs' private IP addresses. Your network administrator has configured whether that server is accessible to the pod's management or tenant subnet's IP address range. The internal gateway's resource group in Microsoft Azure has four (4) NICs that correspond to that subnet: two that are currently active for the two Unified Access Gateway instances and two NICs that are idle and will become the active ones after the pod goes through an update. To support the communication connectivity between the gateway and the two-factor authentication server both for ongoing pod operations and after each pod update, you must configure that server to allow client connections from the IP addresses of the four NICs in the internal gateway's resource group in Microsoft Azure that correspond to the subnet that has visibility to that server. See the section below Allowing Communication From the Pod Gateway NICs' IP Addresses.
Note: For an RSA SecurID type configured on the internal gateway, add the NIC IP addresses for the four NICs on the tenant subnet.
RADIUS - External gateway configuration and the two-factor authentication server is accessible inside the pod's VNet
When your network administrator has configured the two-factor authentication server to be accessible on the same VNet as the pod, the Unified Access Gateway instances use their NICs' private IP addresses to contact that server. The two-factor authentication server sees the requests coming from source IP addresses that are the NICs' private IP addresses. Your network administrator has configured whether the server is accessible to the pod's management, tenant, or DMZ subnet's IP address range. The external gateway's resource group in Microsoft Azure has four (4) 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 the communication connectivity between the gateway and the two-factor authentication server both for ongoing pod operations and after each pod update, you must configure that server to allow client connections from the IP addresses of the four NICs in the external gateway's resource group in Microsoft Azure that correspond to the subnet that has visibility to that server. See the section below Allowing Communication From the Pod Gateway NICs' IP Addresses.
RADIUS - External gateway configuration and the two-factor authentication server is accessible outside the pod's VNet
When your network administrator has configured the two-factor authentication server outside of the pod's VNet, the external gateway configuration's Unified Access Gateway instances use the external gateway's Azure load balancer resource's IP address to contact that server. You must configure that server to allow client connections from the external gateway's load balancer resource's IP address. See the section below Allowing Communication From the External Gateway's Load Balancer.

Allowing Communication From the Pod Gateway NICs' IP Addresses

When the pod is deployed, the pod deployer creates a set of NICs in the gateway's resource group in your Microsoft Azure subscription. The following screenshots are examples of the NICs for the internal gateway type and external gateway type. Even though the pod ID is pixelated out in these screenshots, you can see the pattern in which the deployer names the NICs, with -management, -tenant and -dmz in those names. For the names of the pod's resource groups, see Resource Groups Created For a Pod Deployed In Microsoft Azure.


Screenshot of the NICs and VMs that the pod deployer creates for an internal gateway configuration.


Screenshot of the NICs and VMs that the pod deployer creates for an external gateway configuration.

You need to obtain the IP addresses of the NICs for the gateway configuration on which you enabled the two-factor authentication settings which correspond to the subnet which has network visibility to the two-factor authentication server, and specify those IP addresses as allowed clients in that two-factor authentication server's configuration.

Important: To avoid any disruption in connectivity between your two-factor authentication server and the pod after an update, for each gateway that you configured with two-factor authentication settings, ensure that the IP addresses of the four (4) NICs that are described below are specified as allowed clients in your two-factor authentication server's configuration. Even though only half of the NICs are active during ongoing pod operations, they switch when the pod is updated. After a pod update, the other half of the NICs become active and the pre-update NICs go idle until the next pod update, when they switch back again. If you have not added all of the NIC IP addresses, both the active and idle ones, to your two-factor authentication server configuration, the two-factor authentication server will refuse connection requests from the post-pod-update now-active set of NICs, and the login process for end users using that gateway will break.

To obtain the gateway's NIC IP addresses to add to the two-factor authentication server configuration:

  1. Obtain from your network administrator the information about which of the pod's subnets has network visibility to the two-factor authentication server (management, tenant, or dmz).
  2. Log in to the Microsoft Azure portal for your subscription and locate the gateway's resource group.
  3. For the NICs that correspond to the subnet that your network administrator says has visibility to the two-factor authentication server, click on each NIC and copy its IP address.
  4. Follow the documentation for your type of two-factor authentication system to add those IP addresses so that the two-factor authentication server accepts communications from those NICs.
Example of adding the gateway's NICs IP addresses when using a RADIUS two-factor authentication server
The following codeblock is an illustration of a portion of the client configuration lines for the NICs with IP addresses on the pod's tenant subnet for an internal gateway where the network administrator configured the RADIUS server inside the same VNet as the pod and with accessibility from the pod's tenant subnet. The pod's tenant subnet was configured as 192.168.25.0/22 when this pod was deployed. When the pod is initially deployed, the NIC1 and NIC2 are active and NIC3 and NIC4 are idle. However, all four of those NICs are added to the RADIUS server configuration to ensure that after the pod updates, when NIC3 and NIC4 become active and NIC1 and NIC2 go idle, the RADIUS sever will continue to accept connections from this gateway. Please note that you must use the appropriate syntax specific to your RADIUS server.
client UAGTENANTNIC1 {
  ipaddr = 192.168.25.5
  secret = myradiussecret
}
client UAGTENANTNIC2 {
  ipaddr = 192.168.25.6
  secret = myradiussecret
}
client UAGTENANTNIC3 {
  ipaddr = 192.168.25.7
  secret = myradiussecret
}
client UAGTENANTNIC4 {
  ipaddr = 192.168.25.8
  secret = myradiussecret
}

RADIUS Two-Factor Authentication - Allowing Communication From the External Gateway's Load Balancer

When the two-factor authentication server is located outside of the pod's VNet, for the external gateway on which you specified that server, you must add the external gateway's Azure load balancer resource's public IP address as an allowed client in that two-factor authentication server's configuration. You can obtain that load balancer IP address by using the Microsoft Azure portal and locating the load balancer resource in the gateway's resource group.

  1. Log in to the Microsoft Azure portal for your subscription and locate the gateway's resource group.
  2. In the gateway's resource group, click on the load balancer resource. It has a name in the pattern vmw-hcs-podID-uag-lb. Its IP address is listed in its overview information.
  3. Follow the documentation for your type of two-factor authentication system to add the gateway's load balancer IP address so that the two-factor authentication server accepts communications from that IP address.
Example of adding the external gateway's load balancer IP address when using a RADIUS two-factor authentication server
The following codeblock is an illustrating example. Please note that you must use the appropriate syntax specific to your RADIUS server.
client MYPODUAGEXTLBIP {
  ipaddr = 52.191.236.223
  secret = myradiussecret
}