Session Protection with VMware Horizon

Introduction

When launching an entitlement using the HTML client with Horizon Blast either through Workspace ONE Access or as a Direct connection with the broker by default one might observe the following:

You might notice that the Browser constantly gets stuck even though our Connection server had trusted CA signed certificates from a public source.

The problem also occurs wheen using HTML blast via Workspace ONE Access, even though Workspace ONE Access is using CA-signed certificates.

The result is an unsatisfactory User-Experience, a user would have to accept what appears to be an Invalid certificate, leaving them with concerns about the resource they are consuming

In this Chapter we will look at what the default configuration is of a session is, exactly what happens and how we can make sure our sessions are secure.

 

Background

In earlier versions of Horizon, if we wanted to solve this problem we had to perform two primary operations.

1st an edit had to made on the Broker to the LDS database using ADSIEDIT. The reason for this is as follows and it entails understanding how the transport works. The 2nd step entailed replacing the Agents self-signed cert with a CA signed cert. In a non-persistant environment the most practical way to do this was to use a wild-card certificate.

This exercise is divided into two parts.

  • Part 1 will cover understanding this issue with the Transport
  • Part 2 we will use the latest approach to configuring Horizon Blast with Workspace ONE Access and you will notice how much better it works.

Part 1. Validating the default configuration on the Blast transport

  1. On the ControlCenter server. Open up your Chrome browser session
    • Select the Access short cut in the favourites bar for Workspace ONE Access, that being https://access.euc-livefire.com, select Next
    • In the Select your domain, ensure euc-livefire.com is the selection. Select Next
  • Enter the user name User 4 and the password VMware1! Select Sign in
  1. In the Workspace ONE Access Console
    • Select Apps
    • Under Categories, select Virtual
    • Select and launch, any one of the 4 entitlements
  1. In the address bar, notice you have an IP address, also you will notice it says the certificate is not Valid.
  1. So there are two problems here, our Agent is using a self-signed cert, but even if we had a CA signed cert it would not be trusted as by default Horizon prefers to use IP address rather than domain name.
    1. In the past this was a two part process, where we had to edit the LDS database using ADSIEDIT (above screenshot of the config) and we would have configure Horizon to Prefer using a FQDN rather than an IP Address. The reason for this was, even if we had a valid certificate it would not be recognized as the address in the certificate would not map to the address in the browser.
    2. On the virtual desktop we would replace the self-signed cert with a CA signed Wild CARD cert .
      • And that was a problem as no one liked that, it was not secure, it gave the impression of being secure, but it was an open door waiting to be exploited.
    3. Thankfully this issue has been rectified and we will look at Part 2 on how secure our Horizon environment properly when we integrate with Access using the Blast Protocol
  • Reference
    • https://kb.vmware.com/s/article/2088354
    • https://docs.vmware.com/en/VMware-Horizon-7/7.5/horizon-installation/GUID-8E7FBB9D-F2DB-4787-B11B-7506126DEB7F.html

Part 2. Securing a Horizon Blast sessions using HTML Access.

What the Product development team have done is give us the ability to Tunnel HTML Blast traffic through the Broker.

  • This has a two advantages. The Broker can use its own CA signed certificate when launching the session with the client and we do not have to configure the Broker to prefer to use DNS as the client is connecting directly with the Broker.
  • Best practice now is to configure the HTML BLAST SECURE GATEWAY on the Broker for internal Horizon Clients. In the past we would not configure Blast to Tunnel through the Horizon Connection Server if we wanted to use the Unified Access Gateway.
  • With this new configuration we are able to use this Connection Server for both Internal and External use.
    • We will now implement this configuration on the Horizon Connection server and then test this configuration out in this Part

 

  1. On your ControlCenter server, launch the Chrome Browser, select the Horizon shortcut in the Favourites Bar
    • Login as Administrator
    • For password us VMware1!
    • Select Sign in
  1. In the Horizon Console
    • Expand Settings
    • Select Servers under Settings
  1. Under Servers, select Connection Servers
  1. On the Connection Servers tab, select the CS1-PD1 and select Edit
  1. Notice the default configuration under Blast Secure Gateway is selected to Do not use Blast Secure Gateway
  1. Change the default configuration by selecting the radio button next to Use Blast Secure Gateway for only HTML Access Connections to machine
    • Close the Edit Connection Server Settings by selecting OK

Part 3 . Validating our Horizon HTML Blast Configuration

  1. On the ControlCenter server. Open up your Chrome browser session
    • Select the Access short cut in the favourites bar for Workspace ONE Access, that being https://access.euc-livefire.com, select Next
    • In the Select your domain, ensure euc-livefire.com is the selection. Select Next
  • Enter the user name User 4 and the password VMware1! Select Sign in
  1. In the Workspace ONE Access Console
    • Select Apps
    • Under Categories, select Virtual
    • Select and launch, any one of the 4 entitlements
  1. Notice there were no hiccups in the launch of your application in your browser and you have a valid certificate in your Browser
    • You are not being redirected to have a direct session with the Desktop

Conclusion

In this session we have seen how we secure internal HTML Blast traffic

If we were external our traffic would tunnel through the Blast Secure Gateway on the UAG. However, when external we would not then tunnel again through the Horizon Connection server. The Unified Access Gateway would come into play. In the next part we will look at how we configure the Unified Access Gateway for secure the HTML Blast Transport for external Access.

Part 4: Securing the HTML Blast Transport using the Unified Access Gateway

  1. On your ControlCenter server,
    • Launch your Chrome Browser
    • Select the UAG-HZ shortcut in the Favourites Bar
    • In the Username area Enter admin, in the Password area enter VMware1!
    • Select Login
  1. In Unified Access Gateway Admin Console under Configure Manually, click Select
  1. Under General Settings next to Edge Services Settings, move the toggle from the left to the right to enable Edge Service Settings
  1. In the Edge Service Settings area, to the right of of Horizon Settings, select the GEAR
  1. In the Horizon Settings window next to Enable Horizon, move the Toggle from left to right
  1. In the Horizon Settings validate the following configurations, next to : -
    1. Connection Server URL * :  https://192.168.110.90
    2. Enable PCOIP : Enabled ( has no relevance to this lab)
    3. PCOIP External URL :  172.16.20.11:4172 (has no relevance to this lab)
    4. Enable Blast : Enabled
    5. Blast External URL : https://uag-hz.euc-livefire.com:443
      • (If we did not configure this the default port would be 8443, this applicable UDP and TCP traffic)
    6. Enable UDP Tunnel Server : Enabled
    7. Blast Proxy Certificate. NOT enabled
      • If the user manually uploads the same certificate for the Unified Access Gateway to the load balancer and needs to use a different certificate for Unified Access Gateway and Blast Gateway, establishing a Blast desktop session would fail as the thumbprint between the client and the Unified Access Gateway does not match. The custom thumbprint input to Unified Access Gateway or Blast Gateway resolves this by relaying the thumbprint to establish the client session. If we were to use this we would also have to configure a Thumbprint
    8. Enable Tunnel: Enabled
    9. Tunnel External URL: https://uag-hz.euc-livefire.com:443
    10. Tunnel Proxy Certificate. NOT enabled
      • same definition as step 7
    11. Select Save
  1. We will now test to see if this configuration works
    • On the ControlCenter server desktop, open the Remote Desktops folder
    • Launch the w10EXT01a.RDP shortcut (you will automatically be logged in)
  1. On the w10EXT01a desktop launch your Google Chrome browser
  1. In the browser address bar, type uag-hz.euc-livefire.com
    • Select the VMware Horizon HTML Access shortcut
  1. Notice you have a Failed to connect to the Connection Server issue
    • Select OK to close the Error message
    • This is not a UAG issue and nothing is broken. This due to a new secure feature that has been enabled in Horizon 7 called Origin checking which is enabled by default and is a new standard defined in RFC 6454
      • https://docs.vmware.com/en/VMware-Horizon-7/7.1/com.vmware.horizon-view.security.doc/GUID-AA5D0A57-51A7-4FC1-A79B-AFD15A72499A.html
  1. On your ControlCenter server Desktop
    • Open your Remote Desktops folder
    • Launch the cs1-pd1 RDP client.
  1. On your Connection server browse to your logs folder to validate this is the issue.
    • On the Task bar launch File Explorer
    • Go to c\:ProgramData\VMware\VDM\logs
    • Open the most current debug log and
    • Search for a keyword "unexpected origin"
  • This validates the issue we are having. To solve this proceed with the following in step 13
  1. To get this working create a file called locked.properties and add associated configurations
  • Proceed with the following steps:
    • In File Explorer browse to C:\Program Files\VMware\VMware View\Server\sslgateway\conf
    • In the Conf folder, right-click > New > Text Document
    • Name the file locked.properties
    • In the Rename window, select Yes
  1. In the Conf folder, select and right-click the locked.properties file
    • Select Edit with Notepad++
  1. Add the following 3 lines to the locked.properties file
  • checkOrigin=false
    balancedHost= uag-hz.euc-livefire.com
    portalHost.1= uag-hz.euc-livefire.com
  • Select Save for your locked.properties file
  • Close the locked.properties file
  • From Start, Restart the Connection server.
    • Give the Connection server 5 minutes to restart and services to come back up and running
  1. On the ControlCenter server, switch back to your w10EXT01a RDP session
  1. In the Login window type in the following:
    • Username: User4
    • Password:VMware1!
    • Select Login
  1. In the Horizon HTML entitlements, launch any of the 4 entitlements
  1. Notice your entitlement launches without any further prompts

Conclusion

This concludes this part

We have Configured HTML Blast for external access using the Unified Access Gateway and the HTML Blast Secure Gateway

Part 5:  Configuring the Transport of Workspace ONE ACCESS for secure Horizon Blast Access

Introduction

When configuring the Transport integration with Workspace ONE Access a customer might have deployed an On-premises, LAN deployed Workspace ONE Access server or DMZ deployed Workspace ONE Access server or the customer might have subscribed to a SAAS deployment of Workspace ONE Access.
VMware Horizon 7 will always be on a Microsoft Active Directory Domain joined LAN connected network. The Unified Access Gateway will be deployed in the DMZ to facilitate all external access for Horizon Based resources and will not be domain joined.

Internal Users should / could connect and tunnel directly through the Connection Server with HTML Blast or have a direct session to the Horizon Agent on the LAN.

External Users should always connect and tunnel via the Unified Access Gateway and should never have a Direct session on the Transport from an external network to a domain joined desktop.

In this scenario all we are doing is securing North / South traffic and to ensure East / West traffic within networks are secure we would have to use VMware NSX

The objective of this session is demonstrate the Networking configuration requirements when Workspace ONE Access integrates with VMware Horizon and the VMware Unified Access Gateway.

  1. On your ControlCenter server, open your Google Chrome browser and select the Access shortcut in the Favourites bar
    • Ensure that in the Select your Domain window, you have System Domain selected in the dropdown
    • Select Next
    • Please Note!  If you get an Access Denied error message in this part when trying to authenticate, it means we have a problem in the Workspace ONE Access, Access Policies.
      • In your browser address bar type the following to bypass the Access Policies
        • https://access.euc-livefire.com/SAAS/auth/0
  1. Under Username type admin, under Password type VMware1!
    • Select Sign In
  1. In the Workspace ONE Access console, select the Identity & Access Management tab
  1. Under Identity & Access Management select Policies
  1. In the Policies window,  select NETWORK RANGES
  1. Under Network Ranges select + ADD NETWORK RANGE
  1. In the Add Network Range window add the follow
    • Under Name type External
    • Under IP Ranges type 172.16.30.1 To 172.16.30.254
    • Select SAVE
  • In the Real world for external we leave the default All Ranges, as we dont have external access we will emulate an external network
    • In this setup the 172.16.30.x network we are treating as an external network for our configurations
  1. In the Network Ranges window select + ADD NETWORK RANGE
  1. In the Add Network Range window add the follow
    • Under Name type Internal
    • Under IP Ranges type 192.168.100.1 To 192.168.100.254
    • Select +ADD ROW twice
    • Under IP Ranges (2nd Row) type 192.168.110.1 To 192.168.110.254
    • Under IP Ranges (3rd Row) type 172.16.10.1 To 172.16.10.254
  • In this setup the above networks are all being treating as external networks for our configurations
    • Select SAVE
  • Note!  Do not cut and paste the Ip address's . Its possible you could a message when trying to save that says,  try entering a valid range of IP addresses . If this happens delete all Internal entries and start with Step 9 from scratch
  1. Review your configurations, click to Close the Network Ranges window,
  1. Under Polices , select the radio button next to default_access_policy_set and select EDIT
  1. In the Edit Policy window select Configuration
  1. In the Configuration window, select ALL RANGES next to Windows 10
  1. Configure the Edit Policy Rule window with the following .
    • Next to:-
      • If a user's network range is * select External
      • and user accessing content from * select Windows 10
      • then the user may authenticate using * select Certificate (Cloud Deployment)
      • If the preceding method fails or is not applicable, then select Password (cloud deployment)
      •                                                                                                           and  select VMware Verify
      • If the preceding method fails or is not applicable, then select Password (Local Directory)
    • Select SAVE
  1. In the Configuration window, select ALL RANGES next to Web Browser
  1. In the Edit Policy Rule, change the following, next to :-
    • Next to:-
      • If a user's network range is * select External
      • and user accessing content from * select Web Browser
      • then the user may authenticate using * select Certificate (Cloud Deployment)
      • If the preceding method fails or is not applicable, then select Password (cloud deployment)
      •                                                                                                           and  select VMware Verify
      • If the preceding method fails or is not applicable, then select Password (Local Directory)
    • Select SAVE
  1. Under External select the + ADD POLICY RULE link
  1. In the Add Policy Rule window add the following:
    • Next to :-
      • If a user's network range is * select Internal
      • and user accessing content from * select Web Browser
      • then the user may authenticate using * select Password (cloud deployment)
      • If the preceding method fails or is not applicable, then select Password (Local Directory)
    • Select SAVE
  1. Under internal select the + ADD POLICY RULE link
  1. In the Add Policy Rule window add the following:
    • Next to :-
      • If a user's network range is * select Internal
      • and user accessing content from * select Windows 10
      • then the user may authenticate using * select Password (cloud deployment)
      • If the preceding method fails or is not applicable, then select Password (Local Directory)
    • Select SAVE
  1. In the Edit Policy window,
    • Select the 6 DOTS next to ALL RANGES WORKSPACE ONE App,
      • Ensure this line, is dragged right to the bottom of the order list
    • Select NEXT
  1. In the Edit Policy window, select SAVE
  1. In the Workspace ONE Access console select Catalog > Virtual Apps Collection
  1. In the Virtual Apps Collections window,
    • Select Horizon
  1. In the Horizon settings window, select EDIT NETWORK RANGE
  1. In Network Ranges select External
  1. In the Assign Pods to Network Ranges window under Client Access FQDN enter  uag-hz.euc-livefire.com
    • Select SAVE
    • Select FINISH

Part 6: Securing Workspace ONE Access and VMware Horizon Sessions

  1. On the Controlcenter2 server
    • If not already open, launch your Chrome Browser and select the UAG-HZ shortcut and login as admin and use the password VMware1!, select Login
  1. In the UAG ADMIN Console
    • Under Configure Manually, click the Blue Select button
  1. In the UAG ADMIN Console
    • Under Advanced Settings
      • Select the Gear to the right of JWT Settings
  1. In the UAG ADMIN Console
    • In the JWT Settings window, select Add
  1. In the JWT Settings window, enter the following, next to
    • Name: Workspace ONE Access
    • Dynamic Public key URL: https://access.euc-livefire.com/SAAS/API/1.0/REST/auth/token?attribute=publicKey&format=pem
    • Public key refresh interval: 86400
    • Select Save
    • Select Close
  1. In the UAG Admin Console
    • In the General Settings area
      • Next to Edge Service Settings, select and move the toggle to the right
      • To the right of Horizon Settings, select the GEAR
  1. In the Horizon Settings window
    • At the bottom of the page, select More
    • To the right of JWT Settings select the dropdown and select Workspace ONE Access
    • Scroll to the bottom of the window and select Save
  1. On your Controlcenter2 server
    • Open an existing Access session to the Admin Console: Access.euc-livefire.com
      • If no session is open, Login as Admin and password VMware1!
      • Select the Catalog tab dropdown and select Virtual Apps Collection
      • Under Name, double Click the Horizon hyperlink
  1. In the Horizon window
    • Select the EDIT NETWORK RANGE button
  1. In the Network Ranges window
    • Select External
  1. In the Assign Pods to Network Ranges window
    • Under Wrap Artifact in JWT move the toggle to Yes
    • Under Audience in JWT, enter https://access.euc-livefire.com
    • Select SAVE
    • Select FINISH to close the Network Ranges window

Part 7: Validating Workspace ONE Access Transport Configurations with VMware Horizon

INTRODUCTION

We will test our Workspace ONE Access Console on what is representative of an internal network. We will perform this task on the ControlCenter server which has and IP address of 192.168.110.10. The 192.168.110.x range was one of the networks we defined as Internal

Next we will test our Workspace ONE Access Console on a network that is representative of an External Network. That being the 172.16.30.x Network. We will perform the test on the W10EXT01a virtual machine that has an IP address of 172.16.30.30

  1. On your Chrome Browser on the ControlCenter server, in the top right hand corner, select the 3 DOTS and then select New incognito window
  1. In the Favourites Bar, select the shortcut to the Access server
  1. In the Select your domain window. Validate that the default domain euc-livefire.com is selected and select Next
  1. Under username enter user4, under password enter VMware1!, select Sign in
  1. Next to Favorites, select Apps
  1. Select any of the Virtual App entitlements, I am going to select Calculator
  1. Notice the Address in the Browser is our Horizon Connection server.
    • In this example, We have launched a Virtual Application from Workspace ONE ACCESS and our session is Tunneling through the Connection Server, without any hiccups. Most important is our Workspace ONE Access Policies pointed us directly to the Internal Broker (Connection Server)
    • Select Log out
    • On the Log Off window select OK
    • Close the browser
  1. On your ControlCenter, switch back to your W10EXT01a.RDP session
    • Ensure that any previous login sessions are logged off and closed
    • When ready select Go back to the login page for Workspace ONE Access. If necessary type https://access.euc-livefire.com
  1. On the Select a certificate window
    • select OK
  1. Next to Favorites, select Apps
  1. In the App entitlements,
    • Select Calculator
    • Notice you are again prompted for Username. (This is as a result of TrueSSO not being configured) We will fix this in the next lab
    • In the Password Request enter VMware1! as the password
    • Select Sign in
  1. Notice the Address in the Browser is our Unified Access Gateway server.
    • In this example, We have launched a Virtual Application from Workspace ONE ACCESS and our session is Tunneling through the Unified Access Gateway Server, without any hiccups. Most important is our Workspace ONE Access Policies pointed us directly to the Unified Access Gateway because of the network settings we defined and the Network we using Workspace ONE Access from.
    • Select Log out
    • On the Log Off window select OK
    • Close the browser

Conclusion

In Summary we looked at Best practice with the regard to configuring the Blast protocol for using with  HTML Client. It is important to note that Native Client by default offers the same and possibly better user experience and we do not necessarily, see the errors we see with the HTML client. However best practices and configurations we saw in this exercise apply to both the Native and the HTML client

0 Comments

Add your comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.