Workspace ONE and Horizon: Better Together

Overview

Workspace ONE and Horizon generally accomplish different use cases. Workspace ONE secures the endpoint: pushes configurations/applications/automations to the end user device. Horizon, on the other hand, secures the workload in the cloud. It allows users to access a remote, virtualized desktop (or RDSH application) hosted in a datacenter, from any device. 

This article aims to elaborate on why you should use Workspace ONE and Horizon together - and how that can be done. 

The "How"

For this section on the "how", I'll revisit the bulleted list from above and elaborate on how Workspace ONE and Horizon can work together to achieve those goals. They leverage existing technology/integrations, and will try to reference public documentation for further information. 

• Use a third party identity provider (with MFA) to access Horizon desktops, instead of just Active Directory 

  • For this integration, you would want to use Workspace ONE Access (this can also be done through UAG, but Access offers greater flexibility). This is generally already included with Horizon licensing (though please check the Horizon feature matrix for whether you're allowed to use this for SSO into other apps / cloud versus on-premise hosting). When using Workspace ONE Access, you can use your own third party IdP to sign in, and use a SAML integration between Access and Horizon. You can also leverage MFA tools as well (such as DUO or RSA) prior to accessing desktop entitlements, bolstering security over the default Active Directory username/password combination. 

• Seamless access to Horizon desktops through Unified App Catalog 

  • To pull in horizon entitlements to the unified app catalog, you'll need to deploy the Access connector on prem to a Windows server instance. It will communicate to the Horizon connection server for any user entitlements. When installing the Access connector, be sure to specify custom install (to install the virtual apps service) and specify any and all root and intermediate certificates.

  • Doc: High Level Horizon-Omnissa Access Integration design 

• Check device for compliance prior to accessing VDI desktops, requiring enrollment of devices 

  • There is a feature in Workspace ONE Access where you can require device compliance check as part of an authentication policy. In this case, Horizon desktops will be treated like any other SaaS application, where we use an authentication policy to require a compliance check. See doc links here and here

  • The effect of this is to require Workspace ONE management of devices accessing Horizon VDI. Through this, you can enforce security / passcode / encryption / etc requirements on the device prior to accessing sensitive data in Horizon. 

• Manage persistent desktops in Horizon, across clouds, using Workspace ONE 

  • If you are already using Workspace ONE for management of physical endpoints, it can be used to manage virtual ones as well in persistent Horizon instances. You can use Workspace ONE to not only manage policy on the device, but also lifecycle and update management of the virtual endpoint. You can leverage one console to manage all endpoints. Details on this can be found here. 

• Push/Update Horizon Client on "thick clients" 

  • To be clear, what I mean by "thick clients" are those desktops running Windows (or similar desktop operating systems) that receive the Horizon client. This could be a physical endpoint that is being used by someone with both a managed device and VDI desktop use. This could be repurposing old desktop devices as clients for only Horizon use. You can manage the "thick" client to enforce kiosk / single app mode through a profile for Workspace ONE, such as the Windows one here. Otherwise, you can push (and maintain updates) for the Horizon client following instructions here. 

• Deeper insights into devices accessing Horizon desktops 

  • Following the same vein of enrolling the device that is accessing the Horizon VDI, you can use Workspace ONE Employee Experience / Vulnerability management to gain deep insights into the device accessing the VDI. You can monitor physical utilization of the endpoint (RAM/CPU/HDD usage, wifi strength, etc) in addition to monitoring CVE vulnerabilities. This is critical to ensure that devices that are potentially kiosk devices remain up to date and to keep visibility of security across all devices. 

• DEM policies pushed to physical endpoints through Workspace ONE 

  • As the last point here, you can push DEM policies to physical endpoints. DEM policies are commonly used on Horizon desktops to do things like folder redirection, enable Horizon smart policies, and restrict access to certain parts of the OS. One feature specific to DEM is privilege elevation - where you can specify a file path / process / registry path that elevates the process without giving the end user full administrative rights on the machine. Details on this process can be found here. 

Conclusion

In closing, these are some integration points/synergies that Workspace ONE and Horizon have. They certainly work well on their own, but are best together. If your top priority is user experience or security, using these products together can magnify the desired impact. At the end of the day, if you currently have Horizon and are concerned about security (keeping the workload secure, in the datacenter), you should also care about the devices accessing those virtual desktops and applications. Workspace ONE can take security further ensuring a consistent posture of all devices accessing your corporate network and sensitive data in a Horizon environment.