This article provides detailed, step-by-step instructions for configuring the Universal Broker settings, including the connection FQDN or URL, two-factor authentication, session timeouts, and Horizon feature policies.
Before you can use Universal Broker for the brokering of resources from end-user assignments, you must first configure certain settings.
In the first-time setup of Universal Broker , the configuration wizard opens automatically, as described in Start the Universal Broker Setup.
Then when you find you need to revise the settings during your ongoing use of the service, you can re-open the configuration wizard from the console's Broker page or the Getting Started page.
- Some key points about the two-factor authentication settings in this configuration wizard
- By design, when Universal Broker is configured with two-factor authentication settings, it forms the authentication request and passes it to an external Unified Access Gateway instance which then communicates with the actual authentication server configured in that instance's settings. The Unified Access Gateway then relays the authentication service's response back to the Universal Broker.
- By its default design, the same Universal Broker two-factor authentication settings will be applied tenant-wide, used for each and every pod in the tenant's pod fleet. To use two-factor authentication for Universal Broker, you must first configure the appropriate authentication service on each external Unified Access Gateway instance within every participating pod in your pod fleet. The configurations of external Unified Access Gateway instances must be identical within and across participating pods.
- For example, if you have a blended pod fleet consisting of both Horizon pods and Horizon Cloud pods and you want to use RADIUS authentication, you configure the RADIUS service on each external Unified Access Gateway instance across all of those Horizon pods and Horizon Cloud pods.
Prepare the required system components according to your pod type. Verifying these prerequisites is especially important when you are completing the wizard for the tenant's first-time setup of Universal Broker.
- For Horizon pods (based on Horizon Connection Server technology):
- Configure the required ports, as described in Horizon Pods - DNS, Ports, and Protocol Requirements for Universal Broker.
- Horizon Pods - Install the Universal Broker Plugin on the Connection Server.
- Horizon Pods - Configure Unified Access Gateway for Use with Universal Broker. If you want Universal Broker to use two-factor authentication for your Horizon pods, configure the appropriate two-factor authentication service on each Unified Access Gateway instance within every participating pod. For more information, see Best Practices When Implementing Two-Factor Authentication in a Universal Broker Environment.
- If you want to enable two-factor authentication only for your external users and bypass it for your internal users, Define Internal Network Ranges for Universal Broker.
- Select Universal Broker as your tenant-wide connection broker for Horizon pods, as described in Start the Universal Broker Setup.
- For Horizon Cloud pods (based on the Horizon Cloud pod-manager technology):
Important: Before you submit the final step of the wizard, all your Horizon Cloud pods must be online and in a healthy, ready state. During application of the settings, the Universal Broker service must communicate with the pods and perform some configuration steps on the pods to complete the setup process. If any of the pods are offline or unavailable, the Universal Broker setup fails.
- Verify that the required DNS names for your regional Universal Broker instance are resolvable and reachable. See the "Pod Deployment and Operations DNS Requirements" table in DNS Requirements for a Horizon Cloud Pod in Microsoft Azure.
- Configure the required ports and protocols, as described in the "Ports and Protocols Required by Universal Broker" section in Horizon Cloud Pods - Ports and Protocols Requirements.
- If you want Universal Broker to use two-factor authentication for your Horizon Cloud pods, configure the same type of authentication service on each external Unified Access Gateway instance that's on every participating pod. See Enable Two-Factor Authentication on a Horizon Cloud Pod's Gateways and Best Practices When Implementing Two-Factor Authentication in a Universal Broker Environment.
- If you want to enable two-factor authentication only for your external users and bypass it for your internal users, Define Internal Network Ranges for Universal Broker.
- Select Universal Broker as your tenant-wide connection broker for Horizon Cloud pods, as described in Start the Universal Broker Enablement Using the Horizon Universal Console.
- Open the configuration wizard for setting up Universal Broker.
Otherwise, you can directly open the wizard by clickingand clicking the pencil icon to edit a configuration.
The configuration wizard for Universal Broker appears. In the current release, the wizard sections correspond to settings for the FQDN, authentication, and some defaults applicable to client sessions.
- If you are completing this wizard immediately after the steps in Start the Universal Broker Setup
- In this case, the console usually has displayed the wizard already unless you cancelled out of the wizard before finishing it. If you cancelled out of the wizard at that time before finishing it, directly open the wizard by navigating to Set Up. and clicking
- If you are revising a saved configuration
- Directly open the wizard by navigating to and clicking the pencil icon next to that configuration.
- In the FQDN page of the wizard, configure the settings for the fully qualified domain name (FQDN) of the Universal Broker service. These settings define the dedicated connection address or URL that your end users use to access resources brokered by Universal Broker.
Note: When you modify a subdomain or FQDN setting, it can take some time for the change to take effect across all your DNS servers.
- For Type, select either a VMware Provided or Customer Provided fully qualified domain name (FQDN).
- Specify additional settings for the selected FQDN type.
- VMware Provided
Setting Description Subdomain Enter the unique DNS name of a valid subdomain in your network configuration that represents your company or organization. This subdomain is prefixed to the VMware-provided domain to form the brokering FQDN.Note: Some strings are disallowed or reserved by the system. This category of strings includes generic words like
book, well-known company-owned terms like
gmail, and protocol. coding, and open-source terms like
sql. The system also disallows a category of patterns of those strings such as
mail2, and so on.
However, when you type a disallowed name into this field, the system does not validate the entry at that time. Only when you reach the wizard's final summary step does the system validate the name you typed here and display an error if your entry matches one of the disallowed names. If that happens,enter a different and more unique name here.
Broker URL This read-only field displays the configured FQDN. The FQDN uses the format https://<your sub-domain>vmwarehorizon.com.
Provide this FQDN to your end users to allow them to connect to the Universal Broker service using Horizon Client.Universal Broker manages the DNS and SSL validation of this FQDN.
The following screenshot shows an example of the configuration wizard with the settings for a VMware-provided FQDN filled in.
- Customer Provided
Setting Description Brokering FQDN Enter the custom FQDN that your end users will use to access the Universal Broker service. Your custom FQDN functions as an alias to the automatically generated VMware-provided FQDN that completes the connection to the service.
You must be the owner of the domain name specified in your custom FQDN and provide a certificate that can validate that domain.Note: Your custom FQDN, also known as the connection URL, represents your company or organization. Ensure that you have the proper authorization to use this custom FQDN.Note: Your custom FQDN must be unique and distinct from the FQDNs of all Unified Access Gateway instances within your pods.Important: You must create a CNAME record on your DNS server that maps your custom FQDN to the VMware-provided FQDN representing the internal connection address of the Universal Broker service. For example, the record might map
Click Browse and upload the certificate (in password-protected PFX format) that validates your brokering FQDN. The certificate must meet all of the following criteria:
- Certificate must be valid for at least 90 days
- Certificate must be signed by a trusted CA
- Either the certificate's Common Name (SN) or any of its Subject Alternative Names (SANs) must match the FQDN
- Certificate's content must conform to standard X.509 format
The PFX file must contain the entire certificate chain and the private key: domain certificate, intermediate certificates, root CA certificate, private key.
The Universal Broker service uses this certificate to establish trusted connection sessions with clients.Note: The certificate can contain a wildcard FQDN in the CN or SAN field. If the wildcard character is the only character in the leftmost subdomain of the reference identifier, only FQDNs matching that leftmost subdomain are validated by the certificate. For example, if the certificate contains the wildcard FQDN
*.mycompany.com, the matching rule allows
vdi.mycompany.comas a valid brokering FQDN. However,
test.vdi.mycompany.comdoes not match the reference identifier and is not allowed.
Password Enter the password for the PFX certificate file. VMware Provided FQDN This read-only field displays the VMware-provided FQDN that is automatically generated for the brokering service. The FQDN takes the format https://<auto-generated string>.vmwarehorizon.com.
The VMware-provided FQDN is not visible to end users and represents the internal connection address of the Universal Broker service. Your custom FQDN functions as an alias to the VMware-provided FQDN.Important: You must set up an alias association by creating a CNAME record on your DNS server that maps your custom FQDN to the VMware-provided FQDN. For example, the record might map
The following screenshot shows an example of the configuration wizard with the settings for a custom FQDN filled in.
- When you are finished configuring the FQDN settings, click Next to proceed to the next page of the wizard.
- (Optional) In the Authentication page of the wizard, configure two-factor authentication.
By default, Universal Broker authenticates users solely through their Active Directory user name and password. You can implement two-factor authentication by specifying an additional authentication method. For more information, see Best Practices When Implementing Two-Factor Authentication in a Universal Broker Environment.
Setting Description Two-Factor Authentication
To use two-factor authentication, enable this toggle.
When you enable the toggle, you are presented with additional options for configuring two-factor authentication.
Maintain Username Enable this toggle to maintain the user's Active Directory user name during authentication to Universal Broker. When enabled:
- The user must have the same user name credentials for the additional authentication method as for their Active Directory authentication to Universal Broker.
- The user cannot change the user name in the client login screen.
If this toggle is turned off, the user is allowed to type a different user name in the login screen.
Specify the authentication method that the Universal Broker should use with the end users in addition to the Active Directory user name and password. The user interface displays two choices RADIUS and RSA SecurID.
This setting applies tenant wide. The behavior in the end-user client will depend on the composition of the tenant's pod fleet and which two-factor authentication type is configured on the pods' gateways, as follows:
- Horizon pods only
- The type you select here is the one used in the client.
- Horizon Cloud pods only
- Select the type that matches the one that is configured on the pods' external gateways.
- Mixture of Horizon pods and Horizon Cloud on Microsoft Azure deployments
In a blended fleet, when
RADIUS is selected here, users' RADIUS authentication requests are attempted through the
Unified Access Gateway instances of both pod types.
In a blended fleet, when RSA SecurID is selected here, the client behavior depends on whether your Horizon Cloud on Microsoft Azure deployments are configured with RSA SecurID on their external gateways.
- If your Horizon Cloud on Microsoft Azure deployments do not have RSA SecurID type configured on their gateways, and RSA SecurID is selected here, users' RSA authentication requests are attempted through the Unified Access Gateway instances of your Horizon pods only. The Active Directory user name and password authentication requests are attempted through the Unified Access Gateway instances of either Horizon pods or Horizon Cloud pods.
- If your Horizon Cloud on Microsoft Azure deployments have the RSA SecurID type configured on them, then users' RSA authentication requests are attempted through the Unified Access Gateway instances of both pod types.
Show Hint Text
Applicable for RADIUS type. Enable this toggle to configure a text string that displays in the client login screen to help prompt the user for their credentials to the additional authentication method.
Custom Hint Text
This field is available when you select to show hint text. Applicable for RADIUS type.
Enter the text string that you want to display in the client login screen. The specified hint appears to the end user as
Enter your DisplayHint user name and password, where DisplayHint is the text string you enter in this text box.Note: Universal Broker does not allow the following characters in the custom hint text: & < > ' "
If you include any of these disallowed characters in the hint text, user connections to the Universal Broker FQDN will fail.
This hint can help guide users to enter the correct credentials. For example, entering the phrase Company user name and domain password below for results in a prompt to the end user that states:
Enter your Company user name and domain password below for user name and password.
Skip Two-Factor Authentication
Enable this toggle to bypass two-factor authentication for internal network users connecting to the Universal Broker service. Ensure that you have specified the public IP ranges belonging to your internal network, as described in Define Internal Network Ranges for Universal Broker.
- When this toggle is enabled, internal users must enter only their Active Directory credentials to authenticate to the Universal Broker service. External users must enter both their Active Directory credentials and their credentials for the additional authentication service.
- When this toggle is turned off, both internal and external users must enter their Active Directory credentials and their credentials for the additional authentication service.
Public IP Ranges
This field is visible when Skip Two-Factor Authentication is enabled.
When one or more public IP ranges are already specified on the Broker page's Network Ranges tab, this field is read-only and lists those IP ranges.
When the Broker page's Network Ranges tab does not have public IP ranges already specified, you can use this field to specify the public IP ranges that represent your internal network, for the purpose of skipping the two-factor authentication prompts for traffic coming from those ranges. Universal Broker considers any user connecting from an IP address within one of these ranges to be an internal user.
For more details about the purpose of specifying these ranges, see Define Internal Network Ranges for Universal Broker.The following screenshot shows an example of the configuration wizard with two-factor authentication settings filled in for the RADIUS type.
When you are finished with your selections, click Next to proceed to the next page of the wizard.
- In the Settings page of the configuration wizard, configure Durations settings for Horizon Client.
These timeout settings apply to the connection session between Horizon Client and the assigned desktop allocated by Universal Broker. These settings do not apply to the user's login session to the guest operating system of the assigned desktop. When Universal Broker detects the timeout conditions specified by these settings, it closes the user's Horizon Client connection session.
Setting Description Client Heartbeat Interval Controls the interval, in minutes, between Horizon Client heartbeats and the state of the user's connection to Universal Broker. These heartbeats report to Universal Broker how much idle time has passed during the Horizon Client connection session.
Idle time is measured when no interaction occurs with the end-point device running Horizon Client. This idle time is not affected by inactivity in the login session to the guest operating system that underlies the user's assigned desktop.
In large desktop deployments, increasing the Client Heartbeat Interval might reduce network traffic and improve performance.
Client Idle User Maximum idle time, in minutes, allowed during a connection session between Horizon Client and Universal Broker.
When the maximum time is reached, the user's authentication period expires, and Universal Broker closes all active Horizon Client sessions. To reopen a connection session, the user must reenter their authentication credentials on the Universal Broker login screen.Note: To avoid disconnecting users unexpectedly from their assigned desktops, set the Client Idle User timeout to a value that is at least double that of the Client Heartbeat Interval.
Client Broker Session Maximum time, in minutes, allowed for a Horizon Client connection session before the user's authentication expires. The time starts when the user authenticates to Universal Broker. When the session timeout occurs, the user can continue to work in their assigned desktop. However, if they perform an action (such as changing settings) that requires communication with Universal Broker, Horizon Client prompts them to reenter their Universal Broker credentials.Note: The Client Broker Session timeout must be greater than or equal to the sum of the Client Heartbeat Interval value and the Client Idle User timeout. Client Credential Cache Timeout
This setting is intended as the Universal Broker comparable to the Horizon Connection Server setting labeled as Other clients. Discard SSO credentials.
Therefore, the description here for this setting is written to match the description for that Horizon Connection Server setting and in the console's tool tip for this setting.
This setting is for clients that do not support application remoting. Discards SSO credentials after the specified number of minutes. Users must log in again to connect to a desktop after the specified number of minutes regardless of any user activity on the client device. The default is 15 minutes.
- In the Settings page of the configuration wizard, configure Policy Details.
Policy Details control whether end users can access certain Horizon features, if the features are available on the desktop and client.
Setting Description Multimedia Redirection (MMR) Enable this toggle to allow your end users access to the Multimedia Redirection feature, if the feature is available on the desktop and client. USB Access Enable this toggle to allow your end users to the USB Redirection feature, if the feature is available on the desktop and client. Clean Up HTML Access Credentials When Tab is Closed
Enabling this setting removes a user's credentials from cache when a user closes a tab that connects to a remote desktop, or closes a tab that connects to the desktop selection page, in the Horizon HTML Access client.
When this setting is enabled, credentials are also removed from cache in the following HTML Access client scenarios:
- A user refreshes the desktop selection page or the remote session page.
- The server presents a self-signed certificate, a user starts a remote desktop, and the user accepts the certificate when the security warning appears.
- A user runs a URI command in the tab that contains the remote session.
When this setting is switched off, the credentials remain in cache.
Allow Client to Wait for Powered-Off VM Enabling this setting allows Horizon Client to retry connection requests to a remote desktop that is currently unavailable.
For example, a client user might request a desktop that is currently powered off. With this setting enabled, Horizon Client can resend its connection request and establish a connection session when the desktop is powered on and available.When you are finished configuring Policy Details, click Next to proceed to the next step of the wizard.
- Review your settings in the Summary page, and then click Finish to save and apply the configuration.
Depending on your system and network conditions, it typically takes at least a few minutes and up to half an hour for the configuration settings to take full effect in the Universal Broker service, as DNS records are propagated across the DNS servers in all global regions. During this time, the Universal Broker service is unavailable. When the setup is completed successfully, the Broker section on the Getting Started page shows the Complete status and the page shows the Enabled status with a green dot.
Important: If the Universal Broker setup fails, the page shows the Error status with a red alert icon. To remediate the configuration failure and set up the Universal Broker service, contact VMware Support as described in VMware Knowledge Base (KB) article 2006985.
What to do next
- If you have configured Universal Broker for Horizon pods, proceed to change the pods to managed state. See Use the Horizon Universal Console to Change a Cloud-Connected Horizon Pod to Managed State.
- If you have configured Universal Broker for Horizon Cloud pods in Microsoft Azure, no further configuration is needed. You can start using the console to create multi-pod images, followed by creating end-user assignments based on those images.