Privileged Access Workstation

Privileged Access

Many organizations are facing the challenge of how to allow users access to their secure applications from a variety of locations and devices. This challenge is now more prevalent than ever as most businesses are adopting a work from anywhere strategy. From the business perspective, the solution needs to be highly secure to mitigate threats. From a user’s perspective, it must be easy to use and accessible.

This document outlines a strategy for securing access to privileged applications that can be achieved using a Omnissa Horizon 8 and Omnissa Workspace ONE. 

With traditional security architecture, the focus is typically on the local network and the perimeters that delineate different areas and security zones. The perimeters usually have firewalls that act as gatekeepers to decide what is allowed into a zone. One downside is if an attacker succeeds in penetrating a perimeter, the attack can move horizontally throughout the entire zone. Because the security is focused primarily on the perimeter, the attack can be very difficult to contain.

The concept of micro-segmentation changes the architecture from a single large zone to multiple smaller boundaries around groups or individual objects. This multi-layered approach includes adding security around the user, their access, the application, and the data, making sure the transport or access is secure, and having a strong knowledge about the user and the device used to request access.

Another key concept to adopt is least-privilege access. The idea is that a user or system should have access to only those resources that are specifically required to perform the task at hand. No more, no less.

Access and security should look across device trust, user trust, transport or session trust, application trust, and data trust. You should establish trust in each to make decisions to grant or deny access.

The Privileged Access Workstation architecture, outlined in this guide, uses these principles to show how to design and build a secure environment.

Security Principles

The following security principles have been applied to the architecture:

Reduce Attack Surface; consideration has been made to reduce the surface of attack by using threat detection and intelligence. This is achieved by securing the edge and apps using micro-segmentation and distributed firewalling and using conditional access policies to provide security controls based on a user, location, or device posture.

Least Privilege principle has been applied so we can provide a user access to the applications the individual needs to perform their job only. Every user is identified as a threat until the necessary compliance checks and authentication is completed.

Clean Source principle has been applied to the workstations. Using a known operating system (OS) build, patch level and controlling the application set along with security baselines and policies means that we are mitigating the security risk of the device accessing the applications.

Monitor and Threat Response; continuous checking of device posture and vulnerability scanning has been included in the architecture using intelligence to provide automated response to threats.

Application Security Levels are applied to define applications access. Users could be offered a full application set with access to very high/high security applications or a limited application set and medium/low security applications. Depending on whether a device is managed or unmanaged, users could access either the full or limited application set.

Mitigate Lateral Traversal has been architected throughout; for example, users who have clearance to access low-risk applications cannot traverse laterally to access high-risk applications. This is realized by using different zones, different virtual desktop/app environments, and securing traffic between zones. This principle allows the architecture blueprint to be used for different tiers of users with different security levels, from IT admins to third-party access.

Conditional Access is a fundamental element of the architecture and is used in the initial connection to determine whether a device is permitted access and what level of applications can be accessed.

Why is it important to have a privileged access strategy?

Securing privileged access is extremely important due to the high impact on the business if the applications, systems, or services are compromised. The outcome could have severe or catastrophic effects on the business, financially, publicly, and operationally.

The types of users requiring privileged access are typically those in a technical role looking to administer systems or services, for example, a domain or network administrator. Naturally, these roles require a high level of access to systems that operate the business and are particularly valuable to hackers. 

Organizations are also being asked to allow their users or third parties access to secure applications, systems, or services of a lower classification. This is even more prevalent due to the pandemic and remote working.

This document outlines an approach to access secure applications of different classifications to address both these requirements.

Overview

The Privileged Access Workstation architecture uses the concept of zones to secure traffic and access before allowing traffic to enter the next zone. It also enables the user to move between security classifications within the organization in a secure manner. This architecture uses the following zones, although in certain situations, some of these zones could be collapsed.

• Device
• Entry zone
• Intermediate zone
• Secure zone

Figure 1: Architecture and Zone Overview

Why do we have multiple zones and a ‘double hop’ to get access to the secure applications?

• Unique security principles can be applied in each zone.
• Higher levels of conditional access can be applied to gain access to the next zone.
• Network traffic can be firewalled to be contained within each zone.
• Often there are different Active Directories that users need to traverse to get access to the applications. For example, a corporate to a secure domain.
• Having two zones allows for logical and physical separation.

The next section will discuss each zone in more detail.

Device

This refers to the device that is being used to initiate access to a secure application, service, or system. The device will be classified as a managed or an unmanaged device.

Why do we classify devices as managed or unmanaged?

• To provide the appropriate level of access to all users.
• To use device compliance as a conditional access requirement and to provide access to different security levels of application based on this classification.
• The organization can be risk-averse and decide to trust a device that is managed by its own policies because it can be comfortable with its security posture.
• Unmanaged devices, however, provide more risk, require more checks, and are granted less access.

Device compliance is not the only metric used for conditional access, as we will uncover in the next zone.

Managed Device

Managed devices are monitored by Omnissa Workspace ONE Unified Endpoint Management (UEM). These components, as well as Omnissa Intelligence, carry out automated responses when a threat, non-compliance, or heightened risk is detected.

A managed device is typically used when the destination applications are designated as secure or high security by the organization and allow the additional information to be used in the evaluation of whether to grant access.

Figure 2: Privileged Access Workstation Logical Architecture for Managed Devices

• A managed device is defined as a device that has the Omnissa Workspace ONE Intelligent Hub and is managed by Omnissa Workspace ONE UEM.
• A device that we know is compliant with the organizations baseline security policies.
• Can be considered for access to a full use desktop and those applications defined as secure or high secure by the organization. Assuming that further authentication requests and conditional access checks are successful in the next zones.
• A typical use case would be an IT domain administrator corporate employee accessing from a company owned device.

Unmanaged Device

An unmanaged device could be a company employees’ personal device or a third-party contractor device. These devices may or may not be managed by an enterprise mobility product and will only be allowed access to a limited desktop and applications defined as a low to medium risk category.

Figure 3: Privileged Access Workstation Logical Architecture for Unmanaged Devices

• An unmanaged device is not managed by the organizations unified endpoint management system and is therefore unknown in terms of its security posture.
• Device will need attestation checks to comply with the organization’s security requirements, such as minimum operating system version and patch level and mandating the device has antivirus installed. For example, OPSWAT can provide this functionality.
• Unmanaged devices can then be considered to access a limited desktop and those applications defined as low or medium secure by the organization, subject to further conditional access and authentication requests.
• A typical use case would be a third-party contractor connecting in to administer a low-risk application (e.g., a reporting or monitoring tool) from a device managed by a different organization.

Entry Zone

The entry zone is the zone protecting access into the environment and enforces least privilege. It is where conditional access and authentication take place.

The following factors can be analyzed before providing access:

• Device compliance check against defined policies, such as minimum OS version, storage encryption, and device passcode complexity.
• Certificate validation checking.
• User risk score, which can be calculated based on known vulnerabilities, user and device actions, and security risks detected by an Endpoint Protection Platform or similar product. See Risk Scoring (Workspace ONE Intelligence Risk Analytics).
• Network location, providing access only from known source IP addresses of the authentication request.

Figure 4: User and Login Risk Score Example Criteria

These conditional access checks are determined by using Omnissa Workspace ONE, specifically Omnissa Access, Omnissa Intelligence, and Omnissa Workspace ONE Unified Endpoint Management.

After all the conditional access checks have taken place, the user will be granted or rejected access to the resources in the intermediate zone. 

Intermediate Zone

The main function of the intermediate zone is to provide a clean source desktop in which to interface with the applications in the secure zone. This is provided by a virtual desktop using Omnissa Horizon 8.

• Depending on whether the user is connecting from a managed or unmanaged device, this desktop will either be full use, and can have access to additional functionality such as a web browser or mail client, or limited use.
• A limited use case is provided a locked-down desktop so only an Omnissa Horizon client can be launched to allow access into the secure zone and apps.
• Additional security and control can be provided to ensure this clean source is delivered using a combination of Windows 10/11 policies, Omnissa Dynamic Environment Manager smart policies, and micro-segmentation, thought technologies such as, NSX identity-based firewalling.
• Some organizations might decide to use a Type 1 Hypervisor on the physical device, with a locked-down guest OS, to connect into an entry zone. This guest OS follows a clean source principle; in this instance, some customers might decide to bypass the intermediate zone and allow direct connection to applications hosted in the secure zone for these devices.

Secure Zone

The main function of the secure zone is to provide an application abstraction layer in which to interface with the applications in the secure zone.

• This is provided by Horizon 8 published applications running on either Remote Desktop Service Hosts (RDSH), or Windows 10/11.
• Many of the same security and control functions provided by Windows, Dynamic Environment Manager, and micro-segmentation, in the intermediate zone are also applicable to the secure zone.
• The secure zone is where the application security levels are defined. The organization can provide access to the specific applications based on their security level and be linked to a specific user or Active Directory security group.

Entry Zone

The objective of the entry zone is to provide users with a secure means of accessing the virtual desktop in the intermediate zone. The virtual desktop is hosted by Horizon 8. Users entitled to access sensitive resources by their administrators can access it from the Omnissa Access catalog.

Components in this zone secure managed devices. For both managed and unmanaged devices, this zone provides conditional access to the intermediate zone based on device security posture and other factors.

This guide covers how to create the entry zone by integrating multiple products – in particular, the Workspace ONE suite.

Third-party products can be used in place of some components to achieve comparable functionality. For example, instead of (or in addition to) Carbon Black Cloud, other endpoint detection and response (EDR) products and mobile threat defense (MTD) products can feed information about device security posture into the Workspace ONE Trust Network.

Components

The following products are used in the entry zone. The minimum required components are:

• Omnissa Workspace ONE Unified Endpoint Management
• Omnissa Access
• LDAP Directory or third-party Identity Provider

In addition, adding the following products and third-party integrations enhance the organization's security posture by further securing access to the privileged access workstation and intermediate zone:

• Omnissa Intelligence aggregates data from Omnissa Workspace ONE UEM, Omnissa Access (if in use), and other sources to calculate user and device risk data, implement automated responses, and inform conditional access.
• Carbon Black to detect and respond to threats in managed devices.

Note: Omnissa Intelligence and Carbon Black and are not dependent on each other, so an organization can elect to add only one of these components.

On-Premises Deployment Considerations

On-premises deployments present limitations in what components can be used:

1. Omnissa Intelligence is a cloud-only offering.
2. In addition, on-premises Workspace ONE Access instances cannot integrate with cloud-hosted Omnissa Intelligence. As such, organizations with on-premises Workspace ONE Access environments cannot use risk scoring.

Workspace ONE Unified Endpoint Management

For managed devices, Omnissa Workspace ONE UEM applies management profiles, ensures device compliance with organization policies, and installs user and device certificates for authentication. The Omnissa Workspace ONE Intelligent Hub client is installed on managed devices. It detects when devices are compromised due to rooting, jailbreaking, or known malware. In the event of compromise, UEM can immediately remove access to corporate resources. Workspace ONE UEM management profiles provide endpoint security features such as protecting enterprise data and apps, setting encryption requirements, managing device password, controlling firewall and antivirus, setting device restrictions, and collecting location information.

For more information, see Workspace ONE UEM Documentation.

Omnissa Access

Omnissa Access serves as the identity provider for resources in the intermediate zone and provides conditional access and authentication. Multi-factor authentication is used for greater security. For more details on how to configure conditional access policies, see Conditional Access and Authentication.

For managed devices, Access integrates with other products in the entry zone to evaluate access to resources.

Figure 5: Information flow to Omnissa Access

• Access queries device compliance status from Workspace ONE UEM.
• Workspace ONE UEM pushes the following to managed devices:
  • Certificates, which the devices use to authenticate with Access
  • If in use, the Carbon Black Cloud Sensor, the client application for Carbon Black Cloud
• From Intelligence, Access can obtain user risk scores. These risk scores are based on device security posture data obtained from Workspace ONE UEM and Carbon Black.

For more information, see Omnissa Access Documentation

LDAP Directory or Third-Party Identity Provider

An LDAP Directory or third-party identity provider can serve as the source of user data for Omnissa Access. These can also be used for password-based authentication for unmanaged devices.

Additional Components

The following components can be added to enhance the organization’s security posture by better securing access to the privileged access workstation and intermediate zone.

Omnissa Intelligence

Omnissa Intelligence is a data aggregation and correlation service for the Workspace ONE platform. It obtains data from other Workspace ONE products:

• Workspace ONE UEM - Applications installed on the device, OS version, and other details about the user’s devices. Intelligence tracks known Common Vulnerability and Exposures (CVEs) and correlates these with the OS version of managed devices to determine what vulnerabilities devices possess.
• Trust Network Integrations - A growing number of partners, covered in Workspace ONE Trust Network, have out-of-the-box integrations with Intelligence.
• Carbon Black Cloud - Threat events for user devices obtained through the modern EDR methods.

Intelligence combines this information to calculate a risk score for the user and their managed devices.

Based on user and login risk score and device compliance status, Intelligence automatically takes actions such as removing access to corporate resources, wiping the device, and creating service desk incident tickets. Risk scores can also be consumed by Access to make decisions on whether to allow access to the intermediate zone, require additional authentication, or deny access.

For more information, see:

• Workspace ONE Intelligence Products
• Freestyle Orchestrator

Conditional Access and Authentication

A single instance of Omnissa Access handles conditional access for both managed and unmanaged devices. An organization might only want to allow managed devices to access their most sensitive applications through a dedicated full-use virtual desktop hosted on a dedicated Horizon instance. To achieve this, organizations can grant conditional access to these dedicated virtual desktops only to managed devices, while allowing unmanaged devices to only access partial-use virtual desktops with access to a subset of resources. This is achieved by:

1. Managing entitlements for full-use and partial-use virtual desktops as separate virtual app collections in Access.
2. Configuring appropriate access policies for each desktop type in the intermediate zone.

Figure 6: Resource Access by Device Type

Managing Privileged and Less-Sensitive Resources as Separate Virtual App Collections

In the entry zone, a single instance of Workspace ONE UEM, Access, and other intermediaries are used to provide access to full-use and partial-use desktops. In contrast, the intermediate zone includes dedicated:

• Separate Horizon 8 VDI instances for full-use and partial-use virtual desktop resources
• Dedicated Omnissa Unified Access Gateway instances for each Horizon instance

To set this up, Access must synchronize resources from the Horizon instance as a separate virtual app collection. This is done integrating Access directly with the Horizon 8 instances via the Workspace ONE Access connector.

Figure 7: Separate Virtual App Collections for Privileged and Less Sensitive Resources

Access Policies for Resources in the Intermediate Zone

To control access to less-sensitive resources through limited desktops, organizations can set up access policies using the following criteria. This allows access from unmanaged devices:

• Multi-factor authentication - This can be done through built-in producs like Omnissa Intelligent Hub or third-party integrations.
• Network ranges - Organizations can restrict access to resources only to devices in specific networks. This can be used to allow access only to devices in secure corporate networks and virtual private networks (VPNs). Administrators can set up a network range in Omnissa Access defining a range of IP addresses and assign different access policies based on that range.
• Certificate-based authentication (CBA) or iOS/Android mobile single sign-on (SSO) with fallback - Managed devices will authenticate using certificates provisioned via Workspace ONE UEM. Users with unmanaged devices will fall back to using password-based authentication or other methods.

In addition to these access policies, organizations should implement additional restrictions for sensitive resources that should only be accessible from managed devices through full desktops. These options include:

• Certificate-based authentication (CBA) or iOS/Android mobile SSO without fallback – Only devices possessing the certificates required for these authentication methods will pass this rule. If these certificates are only distributed through Workspace ONE UEM, only managed devices can access privileged resources.
• Device Compliance (Any Platform) – Only devices that are compliant with Workspace ONE UEM policies will pass this rule.
• Risk Scores - Organizations leveraging Intelligence can factor in user risk scores to allow/deny authentication or to request a step-up authentication method.

Figure 8: Access Policy rules by Resource Type

Authentication Session Length

For each rule in an access policy, the organization sets the number of hours for which authentication is valid. The re-authenticate after value determines the maximum time users have since their last authentication event to access their portal or to open a specific application.

Organizations might want to grant access to privileged resources for a limited period. In such cases, the re-authenticate after value should be considerably smaller than the time window allowed by the organization. This minimizes how much the authentication session can outlast the desired time window.

For example:

• An organization allows a user access to a resource from 12:00 – 16:00
• The user logs in at 15:45
• If the re-authenticate after value is set to:
  • 30 minutes - The authentication session expires at 16:15
  • 8 hours (default value) – The authentication session expires at 23:45

Entry Zone Example - Privileged Resources To access privileged resources, access policies require:

• Certificate-based authentication (Windows 10/11, macOS) or Mobile SSO (Android, iOS)
• Multi-Factor authentication with Verify (Intelligent Hub) or a third-party product
• Compliance with policies in Workspace ONE UEM (device compliance)
• User risk score and user login score to be low or medium

Figure 9: Management and Securing of Managed Devices

The following steps describe the authentication flow for managed devices.

Note: Some steps require Omnissa Intelligence or Carbon Black Cloud.

1. After the device is enrolled via the Intelligent Hub client, Workspace ONE UEM pushes the following to the device:
   1. Management profiles, device certificates, and user certificates. 
   2. The Carbon Black Cloud Sensor client (Carbon Black Cloud required).
2. The device’s security posture is monitored, and automated responses are taken as configured by the organization:
   1. Intelligent Hub reports device posture to Workspace ONE UEM, which evaluates adherence to compliance policies. If devices are non-compliant, Workspace ONE UEM can notify the organization’s administrator, revoke access to all corporate resources, and more.
   2. The Carbon Black Cloud Sensor client reports threat information to Carbon Black Cloud. Carbon Black Cloud executes automated responses. Threat information is forwarded to the Trust Network repository (Carbon Black required).
   3. Intelligence queries the Trust Network repository every 30 seconds for any newly reported threats on the device. Based on:
      1. Threat data from the Trust Network repository (Carbon Black required) and
      2. Security posture details in Workspace ONE UEM

Intelligence takes automated actions as a response, including notifying the organization’s security team via Slack and tagging the device as at risk in Workspace ONE UEM.

Figure 10: Authentication Flow for Managed Devices

3. When the user attempts to access the virtual desktop in the intermediate zone, the device presents Access the certificate provisioned from Workspace ONE UEM.
4. Access evaluates:
   1. The device’s compliance status with respect to compliance policies in Workspace ONE UEM.
   2. The user’s risk score as calculated by Intelligence (Omnissa Intelligence required).
5. If the device is compliant and does not have a high risk score, the user performs multi-factor authentication to access the privileged resource.

Note: It is also possible to create IF/THEN policies. If the user risk is identified as medium then a second authentication factor could be requested, for example.

6. If authentication is successful, Access generates a SAML artifact and assertion.
   1. These are the access tokens that allow the user access to Horizon 8 resources.
   2. The authentication request is sent forward, using the SAML artifact, to the Unified Access Gateway.
7. After the user successfully passes the conditional access rules and launches the application, Access feeds these audit events to Intelligence (Omnissa Intelligence required).

Intermediate Zone

The objective of the intermediate zone is to provide sufficiently authenticated individuals with a clean source virtual desktop, from which they can then securely access permitted high-risk applications in the secure zone.

The intermediate zone uses a standard on-premises deployment of Horizon 8 based upon the reference architecture, the low-level details of which are not covered within this document but can be found in the Workspace ONE and Horizon Reference Architecture.

The implementation makes provision for two distinct intermediate zones to differentiate between access originating from either a managed or unmanaged device. It is expected that managed devices would typically be used for access by employees, with the higher trust level granting them access to an intermediate zone, a full set of high-risk applications and potential browse down capabilities to a subset of corporate resources. Conversely, unmanaged devices would be those used by third parties, contractors and as a fallback for employees, granting them access to a separate intermediate zone and a subset of applications with no browse down capability.

In some circumstances, such as when the security posture of the managed device can be guaranteed, the use of an intermediate zone could be omitted, thereby granting the managed device direct access to high-risk applications published from within the secure zone.

It is imperative that every device attempting to access the intermediate zone has undergone the required authentication and compliance checks performed by the entry zone. Enforcing this flow requires the Horizon 8 environment in the intermediate zone to have Workspace ONE Mode enabled. Workspace ONE Mode ensures that all non-SAML authenticated access via the Unified Access Gateway, i.e., those that have not been authenticated by Access, are redirected to the entry zone for these checks to be performed.

For intermediate zones providing access to unmanaged devices, it is necessary to employ alternative device attestation methods to ensure these devices are not compromised. The Unified Access Gateway offers support in this scenario through tight integration with the lightweight third-party OPSWAT Client which can independently perform the relevant compliance checks on a device.

Figure 11: Intermediate Zone for Managed Devices

Components

The intermediate zone contains the following components.

Unified Access Gateway

Omnissa Unified Access Gateway is a hardened Linux security appliance, which resides in a demilitarized zone (DMZ), and is the secure entry point into the intermediate zone. Running a minimal set of services, to reduce potential attack vectors, the Unified Access Gateway acts as a Layer 7 proxy for external connectivity to the virtual desktops hosted in the intermediate zone. Multiple Unified Access Gateways can be deployed, behind a load balancer, to provide high availability and service scale-out. In addition, the Unified Access Gateway allows the cryptographic protocols, ciphers, and their preference order to be strictly controlled.

Active Directory

Active Directory is the primary method of authenticating users and granting them access to virtual desktops within the intermediate zone. This intermediate zone Active Directory can be the same as the existing corporate Active Directory (AD) or fully independent. However, in both cases access to the privileged access workstation environment should be controlled by an IP Address Management (IPAM) system with access only enabled for an approved duration to perform the required privileged activities.

Typically, the intermediate zone AD would be independent of the secure zone AD. However, a one-way trust relationship could be established to simplify access to the secure zone, e.g., the secure zone AD trusts the intermediate zone AD.

 Horizon Connection Server

The Horizon 8 Connection Server acts as a broker for inbound client connections, authenticating users through Windows Active Directory and directing successful requests to a dynamically provisioned virtual desktop.

In addition, the Horizon Connection Server provides the following management capabilities:

• Entitling users, or groups of users, to specific virtual desktop resources
• Managing remote desktop and application sessions
• Establishing secure connections between users and remote desktops and applications
• Enabling single sign-on
• Setting and applying connectivity policies

Windows Virtual Desktop

Horizon provisions virtual desktops on-demand at logon using instant clones, thereby always providing a clean source principal desktop running the latest, fully security-patched, Windows 10/11 operating system.

• Sterile and lightweight Windows 10/11 virtual machine with minimal application footprint
• Provides antivirus (AV) and Endpoint Detection & Remediation (EDR) capabilities through third-party products
• Employs standard user accounts, ensuring least privileged access to the system
• Reside on an isolated network, denying direct external access to the secure zone

Full clone desktops can also be used if persistence of the operating system is required for forensic analysis.

 Dynamic Environment Manager

Omnissa Dynamic Environment Manager provides end users with a personalized and dynamic Windows desktop, adapted to their specific situation. The configuration can be based on aspects such as the user's role, accessing device and location.

• Application deny- and allowlisting via policy-based rules which prevent groups of users from running certain applications on the system or only permit groups of users to run certain applications.
• Privilege Elevation which enables the use of standard user accounts by default and provides elevation of rights only for select applications or processes when and where necessary.
• Persists Windows and application settings, for example, addition of server configurations to Putty, between sessions to ensure changes are not lost when the user logs out and the desktop is destroyed. This can be particularly important if the environment is offering browse down capability, or has applications installed over and above those needed to access published applications in the secure zone.

Additional Components

The following components, whilst not essential for the implementation of privileged access workstation, are recommended to provide a more secure, adaptable, and robust implementation.

Horizon Enrollment Server

The Horizon Enrollment Server is an optional component which can be employed to provide True single sign-on (True SSO) into virtual desktops where the entry zone leverages non-Active Directory authentication methods, such as certificate-based authentication or RSA SecurID.

The Horizon Enrollment Server integrates with an enterprise certificate authority (CA) to request a short-lived certificate on behalf of a user. This certificate can then be used to sign-on the user to their virtual desktop without the need to prompt for a username or password, thereby offering a much more seamless and secure user experience.

Micro-segmentation

Micro-segmentation technologies enable the definition of fine-grained network zones, down to individual VMs and applications. This can be used to provide a network-least-privilege security model for traffic between workloads within the data center.

In our deployment, we used NSX, which is a software-defined network virtualization platform which extends across datacenters, multi-cloud and container infrastructure. In the context of the intermediate zone, NSX can provide the following capabilities for Horizon 8:

• Network segmentation to ensure the logical isolation of the various security zones detailed in this document.
• Micro-segmentation to ensure logical isolation of the various management systems or virtual desktops within a network segment.
• Identity-based firewall to dynamically permit network access on a per-user basis to only the resources they are entitled to. This can become particularly important where browse down capabilities, to existing intranet hosted corporate resources, is required over and above just accessing applications published from the secure zone.
• Load balancing services for both the Unified Access Gateways and Horizon Connection servers to ensure high availability and easy service scale-out.

For more information, and a list with reviews, on different vendors who provide micro-segmentation products, see the Gartner page on Microsegmentation Reviews and Ratings.

Carbon Black Cloud Sensor

The Carbon Black Cloud Sensor can be deployed to virtual desktops to provide Endpoint Detection & Response (EDR) capabilities. The sensor enables detection and reporting of malicious behavior to the Carbon Black Cloud for intelligent analysis. Post analysis, the sensor can then rapidly enact responses to identified threats to secure the endpoint.

High-Level Access Flow

This section, and associated diagram, detail the high-level access flow phases which an external device undergoes when accessing the intermediate zone.

Figure 12: Communication Flow through Intermediate Zone

1. In-bound Connection
   1. Workspace ONE Mode ensures that any device accessing the Unified Access Gateway without the correct SAML artifact is redirected to Omnissa Access in the entry zone.
   2. Optionally, for unmanaged devices, the Unified Access Gateway will validate a device’s compliance via OPSWAT before permitting access.
   3. The Unified Access Gateway receives the SAML artifact and validates its Java Web Token (JWT) settings to make sure it originates from the trusted identity provider.
   4. The Horizon Connection Server is passed the SAML artifact, performs a SAML resolve against Access, which then validates the SAML artifact and returns an SAML assertion.
2. Broker Desktop Connection
   1. Based upon the SAML assertion the Horizon Connection Server validates the user and their entitlements.
   2. Horizon Connection Server allocates an existing provisioned virtual desktop and provisions additional virtual desktop capacity where necessary.
   3. Optionally, the Enrollment Server receives certificate-signing requests from the Connection Server and requests the trusted certificate authority generate a short-lived certificate on behalf of the user.
3. Virtual Desktop Connection
   1. The Omnissa Horizon Agent installed on the virtual machines allows them to be managed by the Connection Servers and allows a Horizon Client to establish a protocol session to them.
   2. The user is authenticated and logged onto the virtual desktop.
4. Micro-segmentation (Optional)
   1. Micro-segmentation firewall policy rules already applied at time of provisioning by technologies such as NSX.
   2. Micro-segmentation firewall policy rules can be based upon the user identity. This enacts the principle of least-privilege access to the transport level.
5. Session Configuration
   1. Dynamic Environment Manager applies Horizon Smart Policies to control the behavior of remote and data loss prevention (DLP) features of the Horizon desktop.
   2. Dynamic Environment Manager applies and enforces group policy settings.
   3. Dynamic Environment Manager persists user personalization of Windows and permitted applications between sessions.
6. Horizon Client Published Applications Access
   1. Horizon Client facilitates connection to the secure zone to consume permitted published applications.

Secure Zone

The purpose of the secure zone is to publish the secure applications to the virtual desktop in the intermediate zone. 

The secure zone, like the intermediate zone uses a standard on-premises deployment of Horizon 8 based upon the Workspace ONE and Horizon Reference Architecture and Horizon Apps farms to publish the applications.  By only surfacing published applications from the secure zone the user has no low-level operating system access, enforcing the least privilege security principle.

Figure 13: Secure Zone for Managed Devices

Components

Many of the components outlined in the intermediate zones such as Unified Access Gateway, Active Directory, Horizon Connection Server, Dynamic Environment Manager, and NSX, are also used in the secure zone. This section will only cover the unique configurations specific to the secure zone.

Unified Access Gateway

The Omnissa Unified Access Gateway will be used to provide a tunneled reverse proxy type functionality into the secure zone. The Unified Access Gateway can be configured to prompt for additional credentials e.g., multi-factor authentication. Third-party SAML access is also supported.

Note: If you use an authentication mechanism that does not include username and password, for example, SAML only, True SSO must be implemented to provide single-sign-on.

Figure 14: Third-party IdP Integration with Unified Access Gateway

Active Directory

Many organizations will have a dedicated Active Directory in the secure zone. It might be a security requirement to have multiple separate active directories, for example for different third parties or contractors requiring access.

Figure 15: Active Directory Options in the Secure Zone

There are options for domain trusts that have an impact on security and usability:

1. Domain Joined

The connection server is joined to a secure domain. By default, all users of that domain and any other domain connected with a two-way trust can be configured to access the horizon apps. Horizon SSO can be users to pass-through authentication into the RDSH server, there is no additional login required.

2. One-Way trust

A domain for users or groups can be configured with a one-way trust to the connection server domain. By implementing a one-way trust between the secure domains. You must provide secondary credentials for the administrator users in the Horizon Administrator using the vdmadmin -T tool. Horizon SSO can also be used in this configuration.

However, the trust might not be desirable for many secure organizations.

3. Horizon Untrusted Domains

Horizon now gives organizations the ability to configure untrusted domains that do not have a formal trust with the connection server domain. This is done using domain bind accounts.
For more information, see Configuring Untrusted Domains.

As of the Horizon 8 2106 release you can also use SAML, True SSO and Smartcard authentication with untrusted domains.

Horizon Connection Server

Refer to the intermediate domain. The same information can be applied to the secure zone.

Published Applications

Published applications can be delivered using Windows RDSH or Windows 10 Enterprise multi-session mode. Both can be provisioned using instant clones, much like the VDI in the intermediate zone, to provide a clean source principle.

Applications that are installed on the RDSH server/desktop for consumption can be secured using NSX Identity-based firewalling (IDFW). This is a really good use case for IDFW because you can have different users or departments accessing the same remote desktop session host but by defining network rules for applications and linking them to Active Directory accounts you can be granular on which apps they can use.  This reduces the complexity of managing large pools of session hosts and adds greater flexibility, security, and efficiency to the environment.

Dynamic Environment Manager

Refer to the intermediate domain section. The same information can be applied to the secure zone.

Additional Components

Refer to the intermediate zone section. The same information and components can be applied to the secure zone.

High-Level Access Flow

This section, and associated diagram, detail the high-level access flow phases for access to the secure zone from the intermediate zone.

Figure 16: Communication Flow through Secure Zone

1. Users log in to the Horizon Client or Browser using the URL of the Horizon 8 environment in the secure zone from their clean principle VDI in the intermediate zone.
   1. The Unified Access Gateway can be configured to require multi-factor authentication (MFA).
   2. This can be SAML-based MFA to products like Azure, however, this requires external connectivity and associated outbound firewall rules from the secure zone.
   3. RADIUS SecurID authentication can also be used, and this can be kept internal to the secure zone.
2. The Horizon Enrollment Server can be used to enable single sign-on to the Horizon apps in the secure zone.
   1. The Enrollment Server receives certificate-signing requests from the Connection Server and then passes them to the trusted certificate authority to generate a short-lived certificate on behalf of the user.
3. Secure Horizon published application or virtual desktop.
   1. Horizon Agent software service is installed on the guest OS of the virtual machine.
   2. This agent allows VMs to be managed by Connection Servers and allows a Horizon Client to establish a protocol session to the target VM.
   3. Dynamic Environment Manager sets Horizon Smart Policies that control the behavior of remote features of a Horizon desktop or published application session.
4. Micro-segmentation firewall policy based on the user identity is applied through the use of technologies such as NSX. This enacts the principle of least-privilege access to the transport level.

Addressing Multiple Use Cases

The architecture can be used in its entirety or adapted to suit the use case relevant to the organization. For example:

• Deploying the unmanaged device architecture to allow third-party companies to access a limited set of secure applications.
• Deploying the managed device architecture to allow trusted employees to access more restricted applications from their trusted device.

Different use cases can be combined into one architecture, for example, to allow both managed and unmanaged device access. Depending on the security requirements you can also combine the use of certain components to address both managed and unmanaged use cases or choose to keep them separate.

Access, and therefore the security, could be kept separate depending on how a user is accessing the environment and what information is known about the device being used. This allows you to give differing levels of access to which applications a user gets granted access to, depending on the trust of the device they are using. This scenario is shown below.

Figure 17: Addressing Multiple Use Cases

Summary and Additional Resources

To learn more about Omnissa products, visit Tech Zone, your fastest path to understanding, evaluating, and deploying Omnissa products.

Changelog

The following updates were made to this guide.

About the Author and Contributors

This document was written by:

• Jamie Hildred, Senior Client Solutions Architect, Omnissa
• Howard Bliss, Lead Solution Engineer, Omnissa
• Manuel Perez, Solution Architect, Omnissa
• Graeme Gordon, Senior Staff Architect, Omnissa

Feedback

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.