Workspace ONE Access Architecture

This chapter is one of a series that make up the VMware Workspace ONE and VMware Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Workspace ONE and Horizon solutions. This chapter provides information about architecting VMware Workspace ONE Access.

Introduction

VMware Workspace ONE Access (formerly called VMware Identity Manager) is a key component of VMware Workspace ONE®. Among the capabilities of Workspace ONE Access are:

  • Simple application access for end users – Provides access to different types of applications, including internal web applications, SaaS-based web applications (such as Salesforce, Dropbox, Concur, and more), native mobile apps, native Windows and macOS apps, VMware ThinApp® packaged applications, VMware Horizon®–based applications and desktops, and Citrix-based applications and desktops, all through a unified application catalog.
  • Self-service app store – Allows end users to search for and select entitled applications in a simple way, while providing enterprise security and compliance controls to ensure that the right users have access to the right applications.
    Users can customize the Favorites tab for fast, easy access to frequently used applications, and place the apps in a preferred order. IT can optionally push entries onto the Favorites tab using automated application entitlements.
  • Enterprise single sign-on (SSO) – Simplifies business mobility with an included Identity Provider (IdP) or integration with existing on-premises identity providers so that you can aggregate SaaS, native mobile, macOS, and Windows 10 apps into a single catalog. Users have a single sign-on experience regardless of whether they log in to an internal, external, or virtual-based application.
  • Conditional access – Includes a comprehensive policy engine that allows the administrator to set different access policies based on the risk profile of the application. An administrator can use criteria such as network range, user group, application type, method of authentication, or device operating system to determine if the user should have access or not.
  • Productivity tools – Enables the Hub Services suite of productivity tools such as People Search, Notifications, Mobile Flow, Assistant, and more.

In addition, Workspace ONE Access has the ability to validate the compliance status of the device in VMware Workspace ONE® UEM (powered by AirWatch). Failure to meet the compliance standards blocks a user from signing in to an application or accessing applications in the catalog until the device becomes compliant. By integrating Workspace ONE Access and VMware Workspace ONE® Intelligence you can add user behavior and risk scoring into the access decision.

  • Enterprise identity management with adaptive access – Establishes trust between users, devices, and applications for a seamless user experience and powerful conditional access controls that leverage Workspace ONE UEM device enrollment and SSO adapters.
  • Workspace ONE native mobile apps Includes native apps for iOS, Android, macOS, and Windows 10 to simplify finding, installing enterprise apps, and providing an SSO experience across resource types.
  • VMware Horizon / Citrix – Workspace ONE Access can also be integrated with VMware Horizon, VMware Horizon® Cloud Service, and Citrix published applications and desktops. The Workspace ONE Access handles authentication and provides SSO services to applications and desktops.

Figure 1: User Workspace Delivered by Workspace ONE Access

To leverage the breadth of the Workspace ONE experience, you must integrate Workspace ONE UEM and Workspace ONE Access into Workspace ONE. After integration, Workspace ONE UEM can use Workspace ONE Access for authentication and access to native applications, web, SaaS, Citrix, ThinApp, and VMware Horizon applications. Workspace ONE can use Workspace ONE UEM for device enrollment and management.

See the Guide to Deploying VMware Workspace ONE with Workspace ONE Access for more details.

Workspace ONE Access can be implemented using either an on-premises or a cloud-based (SaaS) implementation model.

To avoid repetition, an overview of the product, its architecture, and the common components are described in the cloud-based architecture section, which follows. The on-premises architecture section then adds to this information if your preference is to build on-premises.

Table 1: Strategy of Using Both Deployment Models

Decision

Both a cloud-based and an on-premises Workspace ONE Access deployment were carried out separately.

Both deployments were sized for 50,000 users.

Justification

This strategy allows both architectures to be validated and documented independently.

Cloud-Based Architecture

In a cloud-based implementation, the Workspace ONE Access Connector service synchronizes user accounts from Active Directory to the Workspace ONE Access tenant service. Applications can then be accessed from a cloud-based entry point.

Figure 2: Cloud-based Workspace ONE Access Logical Architecture

The main components of a cloud-based Workspace ONE Access implementation are described in the following table.

Table 2: Workspace ONE Access Components

Component

Description

Workspace ONE Access tenant

Hosted in the cloud and runs the main Workspace ONE Access service.

Workspace ONE Access Connector

Responsible for directory synchronization and handles some of the authentication methods between on-premises resources such as Active Directory, VMware Horizon, Citrix, and the Workspace ONE Access service.

You deploy the connector by running the Windows-based installer.

 

 

T:{b}Table {Gn+}{/b}:  Implementation Strategy for Cloud-Based Workspace ONE Access 

Decision

A cloud-based deployment of Workspace ONE Access and the components required were architected for 50,000 users.

Justification

This strategy provides validation of design and implementation of a cloud-based instance of Workspace ONE Access.

Tenant Installation and Initial Configuration

Because the Workspace ONE Access tenant is cloud-based, you do not have to make design decisions with regards to database, network access, or storage considerations. The Workspace ONE Access service scales to accommodate virtually any size of organization.

Connectivity to the Workspace ONE Access service is through outbound port 443. This connection is used for directory synchronization, a subset of the supported authentication methods, and syncing entitlements for resources, such as Horizon desktops and apps. Organizations can take advantage of this configuration with no additional inbound firewall ports opened to the Internet.

Initial configuration involves logging in to the Workspace ONE Access service with the provided credentials at a URL similar to https://<company>.vmwareidentity.com.

Workspace ONE Access Connector

The Workspace ONE Access Connector can synchronize resources such as Active Directory, Horizon Cloud, VMware Horizon and Citrix virtual apps and desktops. The connector enables other typical on-premises resources such as RSA SecurID, RSA Adaptive Authentication, RADIUS, and Active Directory Kerberos authentication. The connector typically runs inside the LAN and connects to the hosted Workspace ONE Access service using an outbound-only connection. This means there is no need to expose the connector to the Internet.

Deploying a Workspace ONE Access Connector provides the following capabilities:

  • Synchronization with an enterprise directory (Active Directory/LDAP) to import directory users to Workspace ONE components
  • Workspace ONE Access Connector–based authentication methods such as username and password, certificate, RSA Adaptive Authentication, RSA SecurID, RADIUS, and Active Directory Kerberos authentication for internal users
  • Integration with the following resources:
    • On-premises Horizon desktop and application pools
    • Horizon Cloud Service desktops and applications
    • Citrix-published desktops and applications

With the release of Workspace ONE Access version 20.01, the architecture of the connector was changed. The 20.01 connector is separated into multiple microservices rather than one monolithic service. Currently this means that there is not feature parity between the different connector versions.

The three services of the Workspace ONE Access Connector version 20.01 are separated into Directory Sync, User Authentication, and Kerberos Authentication Service.

Figure 3: Microservices Included in Workspace ONE Access Connector Version 20.01

The correct version of connector should be chosen and deployed based on the use case and required functionality.

Table 3: Workspace ONE Access Connector Support Matrix

Version

Required Functionality

Connector version 3.3 (2018.8.1.0)

Required for ThinApp application repository synchronization.

Connector version 19.03

Required for Horizon and Citrix applications and virtual desktops support.

Connector version 20.01

Recommended to be used only if the use case does not require ThinApp, Citrix, or Horizon support.

 For more information about the connector and the different versions, watch the video VMware Workspace ONE Access 20.01: Overview and Connector Architecture.

Table 4: Implementation Strategy for the Workspace ONE Access Connector

Decision

The Workspace ONE Access Connector version 19.03 was deployed.

Justification

This strategy supports the requirements of Workspace ONE Access directory integration and allows a wide range of authentication methods.

This connector also enables synchronization of resources from VMware® Horizon and Horizon Cloud Service into the Workspace ONE Hub catalog.

Connector Sizing and Availability

Workspace ONE Access Connector can be set up for high availability and failover by adding multiple connector instances in a cluster. If one of the connector instances becomes unavailable for any reason, other instances will still be available.

To create a cluster, you install new connector instances and configure the authentication methods in exactly the same way as you set up the first connector. You then associate all the connector instances with the built-in identity provider. The Workspace ONE Access service automatically distributes traffic among all the connectors associated with the built-in identity providers so that you do not need an external load balancer. If one of the connectors becomes unavailable, the service does not direct traffic to it until connectivity is restored.

See Configuring High Availability for the VMware Identity Manager Connector for more detail.

Note: Active Directory Kerberos authentication has different requirements than other authentication methods with regards to clustering the Workspace ONE Access Connector. See Adding Kerberos Authentication Support to Your VMware Identity Manager Connector Deployment for more detail.

After you set up the connector cluster, the authentication methods that you have enabled on the connectors are highly available. If one of the connector instances becomes unavailable, authentication is still available. Next, you should configure directory synchronization to also be highly available. For instructions, see Configure High Availability for Directory Sync.

Sizing guidance and the recommended number of Workspace ONE Access Connectors are presented in the online documentation. There are some differences between the different connector versions that you need to take into consideration.

Table 5: Strategy for Scaling the Workspace ONE Access Connector Service

Decision

Two instances of Workspace ONE Access Connectors were deployed in the internal network.

Justification

Two connectors are recommended to support an environment with 50,000 users.

 

Connector Installation and Configuration

For prerequisites, including system and network configuration requirements, see Preparing to Install the VMware Identity Manager Connector on Windows.

For installation instructions, see Installing the VMware Identity Manager Connector on Windows.

Be sure to configure the Workspace ONE Access Connector authentication methods in outbound-only mode. This removes any requirement for organizations to change their inbound firewall rules and configurations. See Enable Outbound Mode for the VMware Identity Manager Connector.

On-Premises Architecture

For the on-premises deployment, we use the Linux-based virtual appliance version of the Workspace ONE Access service. This appliance is often deployed to the DMZ. There are use cases for LAN deployment, but they are rare, and we focus on the most common deployment method in this guide.

Syncing resources such as Active Directory, Citrix apps and desktops, and Horizon desktops and published apps is done by using a separate Workspace ONE Access Connector. The Workspace ONE Access Connector runs inside the LAN using an outbound-only connection to the Workspace ONE Access service, meaning the connector receives no incoming connections from the DMZ or from the Internet.

 

Figure 4: On-Premises Workspace ONE Access Logical Architecture

Table 6: Strategy for an On-Premises Deployment of Workspace ONE Access

Decision

An on-premises deployment of Workspace ONE Access and the components required were architected, scaled, and deployed for 50,000 users.

Justification

This strategy provides validation of design and implementation of an on-premises instance of Workspace ONE Access.

The implementation is separated into the three main components.

Table 7: On-Premises Workspace ONE Access Components

Component

Description

Workspace ONE Access appliance

Runs the main Workspace ONE Access Service.

The Workspace ONE Access Service is a virtual appliance (OVA file) that you deploy in a VMware vSphere® environment.

Workspace ONE Access Connector

Performs directory synchronization and authentication between on-premises resources such as Active Directory, VMware Horizon, and the Workspace ONE Access service.

You deploy the connector by running a Windows-based installer.

Database

Stores and organizes server-state data and user account data.

Database

Workspace ONE Access can be set up with an internal or external database to store and organize server data and user accounts. A PostgreSQL database is embedded in the Workspace ONE Access virtual appliance, but this internal database is not recommended for use with production deployments.

To use an external database, have your database administrator prepare an empty external database and schema before you use the Workspace ONE Access web-based setup wizard to connect to the external database. Licensed users can use an external Microsoft SQL Server 2012, 2014, or 2016 database server to set up a high-availability external database environment. For more information, see Create the Workspace ONE Access Service Database.

The database requires 100 GB of disk space for the first 100,000 users. Add another 10 MB disk space for each 1,000 users brought into the system, plus an additional 1 MB for each 1,000 entitlements. For example, if you had 5,000 users and each user was entitled to 5 apps, you would have 25,000 entitlements in total. Therefore, the additional space required would be 50 MB + 25 MB = 75 MB.

For more guidance on hardware sizing for Microsoft SQL Servers, see System and Network Configuration Requirements.

Table 8: Implementation Strategy for the On-Premises Workspace ONE Access Database

Decision

An external Microsoft SQL database was implemented for this design.

Justification

An external SQL database is recommended for production because it provides scalability and redundancy.

Scalability and Availability

Workspace ONE Access has been tested to 100,000 users per single virtual appliance installation. To achieve failover and redundancy, deploy multiple Workspace ONE Access virtual appliances in a cluster. If one of the appliances has an outage, Workspace ONE Access will still be available.

A cluster is recommended to contain three Workspace ONE Access service appliance nodes to avoid split-brain scenarios. See Recommendations for VMware Identity Manager Cluster for more information. After initial configuration, the first virtual appliance is cloned twice and deployed with new IP addresses and host names.

In this reference architecture, Microsoft SQL Server 2016 was used along with its cluster offering Always On availability groups, which is supported with Workspace ONE Access. This allows the deployment of multiple instances of Workspace ONE Access service appliances, pointing to the same database and protected by an availability group. An availability group listener is the single Java Database Connectivity (JDBC) target for all instances.

Windows Server Failover Clustering (WSFC) can also be used to improve local database availability and redundancy. In a WSFC cluster, two Windows servers are clustered together to run one instance of SQL Server, which is called a SQL Server failover cluster instance (FCI). Failover of the SQL Server services between these two Windows servers is automatic.

Figure 5: On-Premises Scaled Workspace ONE Access Architecture

For more information on how to set up Workspace ONE Access in a high-availability configuration, see Using a Load Balancer or Reverse Proxy to Enable External Access to Workspace ONE Access and the Multi-site Deployment section in Workspace ONE Access Configuration.

For guidance on server quantities and hardware sizing of Workspace ONE Access servers and Workspace ONE Access Connectors, as well as TCP port requirements, see System and Network Configuration Requirements.

Network Latency

There are multiple connectivity points between Workspace ONE Access service nodes, connectors, and the backend identity store (that is, AD domain controllers). The maximum latency between nodes and components, within a site cluster, must not exceed 4 ms (milliseconds).

Table 9: Latency Requirements for Various Workspace ONE Access Connections

Source

Destination

Latency Target

Workspace ONE Access service nodes

Microsoft SQL Server

<= 4 ms

Workspace ONE Access Connector

Domain controller (AD)

<= 4 ms

Table 10: Implementation Strategy for On-Premises Workspace ONE Access Appliances

Decision

Three instances of the Workspace ONE Access appliance were deployed in the DMZ.

Justification

Three servers are required to support high availability for 50,000 users.

Table 11: Implementation Strategy for Workspace ONE Access Connectors

Decision

Two instances of Workspace ONE Access Connectors version 19.03 were deployed in the internal network.

Justification

Two connectors are recommended to support an environment with 50,000 users.

Table 12: Cluster Strategy for SQL Servers

Decision

SQL Server 2016 database server was installed on a two-node Windows Server Failover Cluster (WSFC), which uses a SQL Server Always On availability group.

Justification

The WSFC provides local redundancy for the SQL database service.

The use of SQL Server Always On allows for the design of a disaster-recovery scenario in a second site.

Load Balancing

To remove a single point of failure, we can deploy the Workspace ONE Access service in a cluster configuration and use a third-party load balancer. Most load balancers can be used with Workspace ONE Access. The load balancer must, however, support long-lived connections and web sockets, which are required for the Workspace ONE Access Connector communication channel.

Deploying Workspace ONE Access in a cluster not only provides redundancy but also allows the load and processing to be spread across multiple instances of the service. To ensure that the load balancer itself does not become a point of failure, most load balancers allow for the setup of multiple nodes in an HA or active/passive configuration.

The following figure illustrates how load balancers distribute the load to a cluster of Workspace ONE Access appliances in the DMZ. Workspace ONE Access Connector virtual appliances are hosted in the internal network. The connectors communicate to the Workspace ONE Access service nodes through the service URL using an outbound-only connection.

Figure 6: On-Premises Workspace ONE Access Load Balancing and External Access

In this example, the Workspace ONE Access service URL is my.vmweuc.com, and this hostname is resolved in the following ways:

  • External clients resolve this name to 80.80.80.80.
  • All internal components and clients resolve this name to 192.168.2.50.

Split DNS is not a requirement for Workspace ONE Access but is recommended. Workspace ONE Access supports only one namespace; that is, the same fully qualified domain name (FQDN) for Workspace ONE Access must be used both internally and externally for user access. This FQDN is referred to as the Workspace ONE Access service URL.

You might decide to use two load balancer instances; one for external access and one that handles internal traffic. This is optional but provides an easy way to block access from the Internet to the management console of the Workspace ONE Access web interface. Blocking access to the management console is most easily done by simply blocking traffic to https://[ServiceURL]/SAAS/admin/ from external clients.

Although Workspace ONE Access does support configuring load balancers for TLS pass-through, it is often easier to deploy using TLS termination (re-encrypt) on the load balancer. This way the certificates on each Workspace ONE Access service node can be left using the default self-signed certificate.

Certificate Restrictions

Workspace ONE Access has the following requirements for certificates to be used on the load balancer and, if using pass-through, also on each node.

  • Only SHA-256 (and above) based certificates are supported. SHA-1-based certificates are not supported due to security concerns.
  • The required key size is 2048 bits.
  • The full certificate chain must be available.

Note: Workspace ONE Access Connectors must be able to use TCP 443 (HTTPS) to communicate with the Workspace ONE Access service URL.

It could be beneficial to add a redirect from HTTP to HTTPS for the load balancer and for the Workspace ONE Access service URL. This way end users do not have to specify https:// when accessing Workspace ONE Access.

The following features must be supported by the load balancer:

  • TLS 1.2
  • Sticky sessions
  • WebSockets
  • X-Forwarded-For (XFF) headers
  • Cipher support with forward secrecy
  • SSL pass-through/termination
  • Configurable request time-out value
  • Layer 4 support if using iOS Mobile SSO

Table 13: Implementation Strategy for Global and Local Load Balancing

Decision

In this reference architecture, we deployed load balancers for both the local data center and the global load balancer. We used split DNS for the Workspace ONE Access service URL.

Justification

Our load balancer supports the global load-balancing functionality required for the design. Split DNS allows for the most efficient traffic flow.

Multi-site Design

Workspace ONE Access is the primary entry point for end users to consume all types of applications, including SaaS, web, VMware Horizon virtual desktops and published applications, Citrix XenApp and XenDesktop, and mobile apps. Therefore, when deployed on-premises, it should be highly available within a site, and also deployed in a secondary data center for failover and redundancy.

The failover process that makes the secondary site’s Workspace ONE Access appliances active requires a change at the global load balancer to direct the traffic of the service URL to the desired instance. For more information see Deploying Workspace ONE Access in a Secondary Data Center for Failover and Redundancy.

Workspace ONE Access consists of the following components, which need to be designed for redundancy:

  • Workspace ONE Access appliances and the service URL
  • Workspace ONE Access Connectors
  • Database

Table 14: Site Resilience Strategy for On-Premises Workspace ONE Access

Decision

A second site was set up with Workspace ONE Access.

Justification

This strategy provides disaster recovery and site resilience for the on-premises implementation of Workspace ONE Access.

Workspace ONE Access Appliances and Connectors

To provide site resilience, each site requires its own group of Workspace ONE Access virtual appliances to allow the site to operate independently, without reliance on another site. One site runs as the active Workspace ONE Access cluster, while the second site has a passive cluster group. The determination of which site has the active Workspace ONE Access is usually controlled by the global load balancer’s namespace entry or a DNS entry, which sets a given instance as the target for the namespace in use by users.

You can achieve this architecture using one of two methods:

  • Traditional multi-site redundancy with a passive second cluster in Site 2, powered on and ready to handle requests upon failover
  • Using VMware Site Recovery Manager (SRM)

Using Site Recovery Manager greatly simplifies setting up disaster recovery in Workspace ONE Access and is the recommended method for multi-site deployment. For details, see Performing Disaster Recovery for Workspace ONE Access Using Site Recovery Manager.

Both failover methods take about the same amount of time. The traditional method often requires performing manual tasks to achieve failover to the second site; whereas Site Recovery Manager takes some time powering up the replicated virtual machines. In this reference architecture, we focus on the traditional multi-site disaster recovery architecture, mainly because it is the most complex to set up and operate.

For the traditional multi-site architecture, within each site, Workspace ONE Access must be installed with a minimum of three appliances. This provides local redundancy and ensures that services such as Elasticsearch function properly.

A local load balancer distributes the load between the local Workspace ONE Access instances, and a failure of an individual appliance is handled with no outage to the service or failover to second site. Each local site load balancer is also load-balanced with a global load balancer.

At each site, two Workspace ONE Access Connector servers are hosted in the internal network and use an outbound-only connection to the Workspace ONE Access service appliances. These connectors connect over TCP 443 (HTTPS) to the global load balancer and to the Workspace ONE Access service URL. It is therefore critical that the Workspace ONE Access Connectors be able to resolve the Workspace ONE Access service URL.

Table 15: Disaster Recovery Strategy for On-Premises Workspace ONE Access

Decision

A second set of servers was installed in a second data center following the traditional multi-site architecture. The number and function of the servers was the same as sized for the primary site.

Justification

This strategy provides the same disaster recovery capacity for all Workspace ONE Access on-premises services as using the VMware Site Recovery Manager method. But due to the extra complexity in setting up the traditional method, it is beneficial to explain the process in this reference architecture.

Multi-site Database

You must ensure that the database remains accessible in the event of failover to the second site. We support using Site Recovery Manager, replicating the Microsoft SQL database server or using native Microsoft SQL Server functionality.

VMware Identity Manager 2.9 (and later) supports Microsoft SQL Server 2012 (and later) and its cluster offering Always On availability groups. This allows us to deploy multiple instances of Workspace ONE Access that point to the same database. The database is protected by an availability group, with an availability group listener as the single Java Database Connectivity (JDBC) target for all instances.

Workspace ONE Access is supported with an active/passive database instance with failover to the secondary site if the primary site becomes unavailable. Depending on the configuration of SQL Server Always On, inter-site failover of the database can be automatic, though not instantaneous.

For this reference architecture, we chose an Always On implementation with the following specifications: 

  • No shared disks were used.
  • The primary database instance ran in Site 1 during normal production.

Again, this decision was based on our desire to address the extra complexity in setting up and maintaining SQL Always On in comparison to using the Site Recovery Manager method.

Within a site, Windows Server Failover Clustering (WSFC) was used to improve local database availability and redundancy. In a WSFC cluster, two Windows servers are clustered together to run one instance of SQL Server, which is called a SQL Server failover cluster instance (FCI). Failover of the SQL Server services between these two Windows servers is automatic. This architecture is depicted in the following figure.

Figure 7: On-Premises Multi-site Workspace ONE Access Architecture

For this design, Workspace ONE Access was configured as follows:

  • It uses a hot standby deployment.
  • Workspace ONE Access nodes in Site 1 form an Elasticsearch cluster and an Ehcache cluster. Nodes in Site 2 form a separate Elasticsearch cluster and Ehcache cluster.
    • Elasticsearch and Ehcache are embedded in the Workspace ONE Access virtual appliance.
      Note: Elasticsearch is a search and analytics engine used for auditing, reports, and directory sync logs. Ehcache provides caching capabilities.
  • Only the active site can service user requests.
  • An active Workspace ONE Access group exists in the same site as the primary replica for the Always On availability group.

Note: To implement this strategy, you must perform all the tasks described in Deploying Workspace ONE Access in a Secondary Data Center for Failover and Redundancy. One step that is easily overlooked is the editing of the runtime-config.properties file in the secondary data center. For more information, see Edit runtime-config.properties File in Secondary Data Center to Set Read-Only Mode.

All JDBC connection strings for Workspace ONE Access appliances should point to the SQL Server availability group listener (AGL) and not directly to an individual SQL Server node. For detailed instructions about deploying and configuring the Workspace ONE Access, creating SQL Server failover cluster instances, creating an Always On availability group, and configuring Workspace ONE Access appliances to point to the AGL, see the Create and Configure the Availability Group section in Workspace ONE Access Configuration.

If your organization has already deployed Always On availability groups, consult with your database administrator about the requirements for the database used with Workspace ONE Access.

The SQL Server Always On setup can be configured to automatically fail over and promote the remaining site’s database to become the primary.

Table 16: Strategy for Multi-site Deployment of the On-Premises Database

Decision

Microsoft SQL Server was deployed in both sites.

A SQL Always On availability group was used. We chose this option over the simpler Site Recovery Manager one because it needs extra explanation.

Justification

This strategy provides replication of the SQL database to the second site and a mechanism for recovering the SQL database service in the event of a site outage. We chose this option over the simpler Site Recovery Manager one because it needs extra explanation.

Prerequisites

This section details the prerequisites for the Workspace ONE Access configuration.

vSphere and ESXi

See the VMware Product Interoperability Matrices for more details about supported versions.

NTP

Your entire Workspace ONE Access implementation must be correctly time-synchronized. By default, the Workspace ONE Access appliances pick up the time from the underlying ESXi host. Therefore, the Network Time Protocol (NTP) must be correctly configured on all hosts and time-synchronized to an NTP server. You must turn on time sync at the ESXi host level, using an NTP server to prevent a time drift between virtual appliances. If you deploy multiple virtual appliances on different hosts, make sure all ESXi hosts are time-synced.

You can override the default behavior by specifying NTP server settings in the Virtual Appliance Configuration settings on each appliance. For more information see Configuring Time Synchronization for the Workspace ONE Access Service.

Network Configuration

  • Static IP addresses and DNS Forward (A) and Reverse (PTR) records are required for all servers and the Workspace ONE Access service URL.
  • Inbound firewall port 443 must be open so that users outside the network can connect to the Workspace ONE Access service URL load balancer.
  • Other inbound ports might be required, depending on which authentication methods your use cases require.

Active Directory

Workspace ONE Access 20.01 supports Active Directory configurations on Windows 2008 R2, 2012, 2012 R2, 2016, and 2019, with a domain functional level and forest functional level of Windows 2003 and later, including:

  • Single AD domain
  • Multidomain, single forest
  • Multiforest with trust relationships
  • Multiforest with untrusted relationships
  • Active Directory Global Catalog (optional for Directory Sync)

For this reference architecture, Windows Server 2016 Active Directory was used.

Virtual Machine Build

Specifications are detailed in VM Specifications. Each server was deployed with a single network card, and static IP address information was required for each server. Windows Server 2016 was used for the Workspace ONE Access Connector servers. Workspace ONE Access virtual appliances included the required SUSE Linux Enterprise Server (SLES) operating system. IP address information was allocated for each server.

Installation and Initial Configuration

The major steps for on-premises installation and initial configuration of Workspace ONE Access using Connector version 19.03 are depicted in the following diagram.

Figure 8: Workspace ONE Access Installation and Configuration Steps

Workspace ONE Access OVA

The Workspace ONE Access service appliance is delivered as an Open Virtualization Format (OVF) template and deployed using the VMware vSphere® Web Client. For information on deploying the Workspace ONE Access service appliance, see Deploying Workspace ONE Access. Before you deploy the appliance, it is important to have DNS records (A and PTR) and network configuration specified. As you complete the OVF Deployment Wizard, you will be prompted for this information.

Note: In the OVF Deployment Wizard, you must specify the appliance’s FQDN in the Host Name field (not only the host name), as shown in the following figure.

Figure 9: Workspace ONE Access OVF Wizard

After deployment and on the first boot, you must enter passwords for the SSHUSER, ROOT, and ADMIN user. By default, SSH is disabled for the ROOT user. If you want to SSH into the appliance, you must do so using the SSHUSER account, and you can then switch user to ROOT. The ADMIN user is your local administrator in the Workspace ONE Access web console.

After you configure directory sync, VMware recommends that you promote at least one synced user to administrator and use this account for your everyday operations. The local ADMIN password is also used to access the appliance settings page. You can later change both so that they are not the same. For more information, see Manage Your Appliance Passwords.

You will also be prompted to complete database setup. Here, you enter the JDBC connection string, username, and password. For more information, see the Deploy and Set Up Workspace ONE Access Appliances section in Workspace ONE Access Configuration.

Workspace ONE Access Configuration

After initial setup, you can access the Workspace ONE Access web console. Because Workspace ONE Access depends heavily on the Workspace ONE Access service URL, VMware recommends that you configure this service URL first. For more information, see Modifying the Workspace ONE Access Service URL. If you have issues changing the service URL, see the troubleshooting tips in Troubleshooting FQDN Updates: VMware Workspace ONE Access Operational Tutorial.

After you have changed the service URL, do not forget to enable the New User Portal UI. Enter the license key, and generate activation codes for your Workspace ONE Access Connectors. Now is also a good time to turn on logging to an external Syslog server.

Connector Configuration

The Workspace ONE Access Connector is delivered as a Windows installer and is deployed by installing it on an existing Windows machine. For more information about deploying the Workspace ONE Access Connector version 19.03 (the version used in this document), see Installing and Configuring VMware Identity Manager Connector 19.03.0.0 (Windows).

On first boot, you are prompted for the local admin user’s password. This password is used to access the appliance configuration of the Workspace ONE Access Connector. As the final step of the Workspace ONE Access Connector Setup Wizard, you are prompted for the connector activation code generated in the previous step.

Cluster Configuration

The procedure to create a Workspace ONE Access cluster is described in Configuring Failover and Redundancy in a Single Datacenter. Make sure to start the original appliance first and allow it to fully start up all services before powering on the other nodes.

Verify that the Elasticsearch cluster health is green. After the cluster is operational, VMware recommends always powering down the Elasticsearch primary appliance last. When you power the cluster back on, try to always start the Elasticsearch primary appliance first. You can see which appliance is currently the Elasticsearch primary by visiting the Admin console and the Systems Diagnostic page. Under the Integrated Components section, the Elasticsearch – primary node is listed. For troubleshooting Elasticsearch cluster health issues, see: Troubleshooting Elasticsearch Cluster Health: VMware Workspace ONE Access Operational Tutorial.

Directory Configuration

Although using local users (rather than syncing users from an existing directory) is supported, most implementations of Workspace ONE Access do synchronize users from a Microsoft Active Directory. Active Directory configuration involves creating a connection to Active Directory, selecting a bind account with permission to read from AD, choosing groups and users to sync, and initiating a directory sync. You can specify what attributes users in Workspace ONE Access should have. See Set User Attributes at the Global Level for more information.

Note: The required flag for attributes only means, for example, that if a user in Active Directory does not have the attribute populated, the user will not be synced to Workspace ONE Access. If the user has the attribute populated and if Workspace ONE Access has the attribute mapped to its internal attributes, the value will be synced (with or without the required flag set). Therefore, most of the time, you do not need to change attributes so that they are required.

Connectors Updates

Configure all connectors with the same authentication methods and add them to the WorkspaceIDP. The Workspace ONE Access Connector supports adding an external Syslog server for external log collection.

Service Updates

Make sure all the Workspace ONE Access Connectors are added to the built-in idP and verify that authentication methods are configured in outbound-only mode. Configuring network ranges, authentication methods, and access policies are important tasks to complete before allowing users access to Workspace ONE Access.

Application Catalog

Finally, you configure application integration and publish applications in the Workspace ONE Access user catalog. You can specify application-specific access policies.

Integration with Workspace ONE UEM

To leverage the breadth of the Workspace ONE experience, you should integrate Workspace ONE UEM and Workspace ONE Access into Workspace ONE. After integration:

  • Workspace ONE UEM can use Workspace ONE Access for authentication and access to SaaS and VMware Horizon applications.
  • Workspace ONE can use Workspace ONE UEM for device enrollment and management.

See the Workspace ONE UEM and Workspace ONE Access Integration section in Platform Integration and Working with Hub Services and Intelligent Hub App for more details.

Access to Resources Through Workspace ONE Access

Workspace ONE Access powers the Workspace ONE Hub catalog, providing self-service access to company applications for business users. Workspace ONE Access is responsible for the integration with web-based SaaS applications, internal web applications, Citrix, and VMware Horizon for the delivery of virtual desktops and published applications. All these desktops and apps are displayed to the user in the catalog based on directory entitlements.

Based on the types of applications to be delivered to end users, the catalog is configured to integrate with the relevant services.

Workspace ONE Native Mobile Apps

For many users, their first experience with Workspace ONE is through the Workspace ONE native mobile application, VMware Workspace ONE® Intelligent Hub, which displays a branded self-service catalog. The catalog provides the necessary applications for the user to do their job, and also offers access to other company resources, such as a company directory lookup. Native operating features, such as Apple Touch ID on an iOS device or Windows Hello on Windows 10, can be used to enhance the user experience.

The Workspace ONE Intelligent Hub app:

  • Delivers a unified application catalog of web, mobile, Windows, macOS, and virtual applications to the user.
    Through integration, Workspace ONE Access applications are aggregated with Workspace ONE UEM–delivered applications.
  • Provides a launcher to access the web, SaaS apps, and Horizon and Citrix virtual desktops and apps to give a consolidated and consistent way of discovering and launching all types of applications.
  • Gives the user the ability to search across an enterprise’s entire deployment of application resources.
  • Offers SSO technology for simple user access to resources without requiring users to remember each site’s password.
  • Can search the company’s user directory, retrieving employees’ phone numbers, email addresses, and position on the org chart.

Figure 10: Workspace ONE App

The Workspace ONE native app is available from the various app stores and can be deployed through Workspace ONE UEM as part of the device enrollment process. Platforms supported are iOS, Android, macOS, and Windows 10.

SaaS Apps

SaaS applications, such as Concur and Salesforce, are often authenticated through federation standards, such as Security Assertion Markup Language (SAML), to offload authentication to an identity provider. These applications are published through Workspace ONE Access and allow users seamless SSO access while being protected by the rich access policies within Workspace ONE Access.

The cloud application catalog in Workspace ONE Access includes templates with many preconfigured parameters to make federating with the SaaS provider easier. For SaaS providers, where there is no template. Instead, a wizard guides you through configuring the application and entitling users. Workspace ONE Access supports SAML and OpenID Connect protocols for federation. Workspace ONE Access also supports WS-Fed for integration with Microsoft Office 365.

Figure 11: Administrator Adding a New SaaS Application to the Catalog

 

Figure 12: The Intelligent Hub Application Catalog for End Users

Horizon Apps and Desktops

The capability to deliver virtual apps and desktops continues to be a significant value for Workspace ONE users. Workspace ONE Access can be integrated with a VMware Horizon implementation to expose the entitled apps and desktops to end users. Through VMware Horizon® Client for native mobile platforms, access to these resources can be easily extended to mobile devices.

You must deploy the Workspace ONE Access Connector version 19.03 to provide access to Horizon resources from the Workspace ONE Access cloud-based or on-premises service. The connector enables you to synchronize entitlements to the service.

Note: Workspace ONE Access does not proxy or tunnel the traffic to the resource. The end user’s device must be able to connect to the resource, web, or Horizon or Citrix desktops and apps. Establishing access to the resource can be done in many ways, for example, VPN, Per-App VPN, publicized on the Internet, and more.

Refer to Setting Up Resources in VMware Workspace ONE Access (Cloud) or Setting Up Resources in VMware Workspace ONE Access (On-Premises) for more details on how to add applications and other resources to the Workspace ONE Hub catalog.

See the Horizon and Workspace ONE Access Integration section in Platform Integration and the Horizon Cloud and Workspace ONE Access Integration section, also in in Platform Integration.

What's Next?

Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:

  • Overview chapters provide understanding of business drivers, use cases, and service definitions.
  • Architecture chapters explore the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon, App Volumes Dynamic Environment Manager, and Unified Access Gateway.
  • Integration chapters cover the integration of components and services you need to create the platform capable of delivering what you want.
  • Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Horizon, App Volumes, Dynamic Environment Management, and more.

Filter Tags

Workspace ONE Workspace ONE Access Document Reference Architecture Advanced Design Identity / Access Management