Workspace ONE Access Architecture
This chapter is one of a series that make up the Omnissa Workspace ONE and Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Omnissa Workspace ONE and Omnissa Horizon solutions. This chapter provides information about architecting Omnissa Workspace ONE Access.
Introduction
Omnissa Workspace ONE Access is a key component of Omnissa 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, ThinApp packaged applications, 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 can validate the compliance status of the device in Omnissa Workspace ONE UEM (powered by AirWatch). Failure to meet the compliance standards blocks a user from signing into an application or accessing applications in the catalog until the device becomes compliant. By integrating Workspace ONE Access and 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.
- Horizon / Citrix – Workspace ONE Access can also be integrated with Omnissa Horizon 8, 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 Horizon applications. Workspace ONE can use Workspace ONE UEM for device enrollment and management.
See Workspace ONE UEM Integration 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 Omnissa 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, Horizon, Citrix, and the Workspace ONE Access service. You deploy the connector by running the Windows-based installer. |
Table 3: 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 or https://<company>.workspaceoneaccess.com.
Workspace ONE Access Connector
The Workspace ONE Access Connector can synchronize resources such as Active Directory, Horizon Cloud, Horizon 8, 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. With version 22.09, the connector gained feature parity for all use cases and is the recommended type for all deployments. Version 19.03.01 reached end of extended support and will cease to function with hosted Access tenants by end of April 2023.
For more information, read the knowledge base article Discontinuation Notice for Unsupported Omnissa Identity Manager Connector (90808).
The four services of the Workspace ONE Access Connector version 23.09 are separated into Directory Sync, Virtual App Sync, User Authentication, and Kerberos Authentication Service.
Figure 3: Microservices Included in Workspace ONE Access Connector Version 23.09
The correct version of connector should be chosen and deployed based on the use case and required functionality.
Table 4: Workspace ONE Access Connector Support Matrix
| Version | Required Functionality |
| Connector version 23.09 | Recommended, supports Authentication, Horizon Enterprise, ThinApp or Horizon Cloud Service on IBM Cloud or Horizon Cloud Service on Microsoft Azure with Single-Pod Broker. |
For more information about the connector and the different versions:
- Watch the video Workspace ONE Access 20.01: Overview and Connector Architecture.
- Read about Workspace ONE Access Connector 21.08+ as well as the migration of Horizon and Citrix use cases at It's Time to Upgrade to the Latest Version of the Workspace ONE Access Connector.
Table 5: Implementation Strategy for the Workspace ONE Access Connector
| Decision | The Workspace ONE Access Connector version 23.09 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 Horizon into the Workspace ONE Hub catalog. Horizon Cloud resources are synced using the Universal Broker integration. |
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 add the same services as you did for the first connector. You then associate all the connector instances with the existing configuration on the connector authentication methods page. The Workspace ONE Access service automatically distributes traffic among all the connectors associated with the configuration 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.
Note: Active Directory Kerberos authentication has different requirements than other authentication methods with regards to clustering the Workspace ONE Access Connector. See Configuring a Load Balancer for Kerberos Auth Service High Availability 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 Configuring High Availability for Directory Sync in Workspace ONE Access.
Sizing guidance and the recommended number of Workspace ONE Access Connector is presented in the online documentation. For sizing guidance for Connector 23.09, see Workspace ONE Access Connector 23.09 Systems Requirements.
Table 6: 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, see Prerequisites for Installing the Workspace ONE Access Connector.
For system requirements including network ports, see Workspace ONE Access Connector 23.09 Systems Requirements. The requirements also link to a knowledgebase article KB68035 with the up-to-date IP addresses of the Workspace ONE Access and Hub Services Cloud-Hosted services. They include destination and source IPs for customer network configurations (for example, allow lists).
- Destinations are what the connectors, services, or clients communicate to.
- Source IP will communicate to customer services (for example, crl).
Updates to the list will be added to the KB article two weeks prior to being implemented, so it is a good idea to subscribe to the KB article.
For installation instructions, see Installing the Workspace ONE Access 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 7: 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 three main components.
Table 8: 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. |
| Workspace ONE Access Connector | Performs directory synchronization and authentication between on-premises resources such as Active Directory, 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 of disk space for every 1,000 users brought into the system, plus an additional 1 MB for every 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 Workspace ONE Access System and Network Configuration Requirements.
Table 9: 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 Workspace ONE Access 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 Workspace ONE Access 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 10: 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 11: 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 12: Implementation Strategy for Workspace ONE Access Connectors
| Decision | Two instances of Workspace ONE Access Connectors version 23.09 were deployed in the internal network. |
| Justification | Two connectors are recommended to support an environment with 50,000 users. |
Table 13: 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.domain.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, Android Mobile SSO, or Certificate Authentication
Table 14: 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, 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 15: 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 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 the 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 16: 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 were the same as those sized for the primary site. |
| Justification | This strategy provides the same disaster recovery capacity for all Workspace ONE Access on-premises services. |
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.
Workspace ONE Access 21.08 (and later) supports Microsoft SQL Server 2014 (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.
- Elasticsearch and Ehcache are embedded in the Workspace ONE Access virtual appliance.
- 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 17: 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 Omnissa 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 23.09 supports Active Directory on Windows Server 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.
Installation and Initial Configuration
The major steps for an on-premises installation and initial configuration of Workspace ONE Access using Connector version 23.09 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. 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 turned off 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, it is recommended 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 Workspace ONE Access 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, it is recommended 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: 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, see Installing Workspace ONE Access Connector 23.09.
Cluster Configuration
The procedure to create a Workspace ONE Access cluster is described in Configuring Failover and Redundancy for Workspace ONE Access in a Single Data Center. 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, it is recommended to always power 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: 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.
Service Updates
Make sure all the Workspace ONE Access Connectors are added to the Connector Authentication Methods. 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 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 Setting Up Hub Services to Support Workspace ONE Intelligent Hub 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 of web-based SaaS applications, internal web applications, Citrix, and 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, 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 Horizon implementation to expose the entitled apps and desktops to end users. Through 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 23.09 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 Workspace ONE Access (Cloud) or Setting Up Resources in Workspace ONE Access (On-Premises) for more details on how to add applications and other resources to the Workspace ONE Hub catalog.
See the Workspace ONE Access and Horizon Integration section in Platform Integration.
Summary and Additional Resources
Now that you have come to the end of this design chapter on Omnissa Workspace ONE Access, you can return to the reference architecture landing page and use the tabs, search, or scroll to select further chapter in one of the following sections:
- Overview chapters provide understanding of business drivers, use cases, and service definitions.
- Architecture chapters give design guidance on the Omnissa products you are interested in including in your deployment, including Workspace ONE UEM, Access, Intelligence, Workspace ONE Assist, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
- Integration chapters cover the integration of products, components, and services you need to create the environment capable of delivering the services that you want to deliver to your users.
- Configuration chapters provide reference for specific tasks as you deploy your environment, such as installation, deployment, and configuration processes for Omnissa Workspace ONE, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Management, and more.
Additional Resources
For more information about Workspace ONE Access, you can explore the following resources:
Changelog
The following updates were made to this guide:
| Date | Description of Changes |
| 2024-10-11 |
|
| 2024-05-31 |
|
| 2023-07-24 |
|
| 2023-04-13 |
|
| 2021-11-29 |
|
| 2020-04-29 |
|
| 2020-02-27 |
|
Author and Contributors
This chapter was written by:
- Peter Bjork, Omnissa.
- Sascha Warno, Staff Architect, Omnissa.
Contributors:
- 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.
Associated Content
From the action bar MORE button.