Omnissa Access architecture
Introduction
Omnissa Access is a key component of Omnissa Workspace ONE. Among the capabilities of Omnissa 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, Horizon virtual applications and desktops, Citrix-based applications and desktops, App Volumes applications for Windows, and ThinApp packaged applications, 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 an existing identity provider so that you can aggregate SaaS, native mobile, macOS, and Windows apps into a single catalog. Users have a single sign-on experience regardless of whether they log into 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.
In addition, Omnissa Access can validate the compliance status of the device in Omnissa Workspace ONE UEM. 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 Omnissa Access and Workspace ONE Intelligence, you can add user behavior and risk scoring into the access decision.
Omnissa Access also offers a broad range of authentication methods, such as certificate-based authentication, Mobile SSO, and Omnissa Pass. - Productivity tools – Enables the Hub Services suite of productivity tools such as People Search, Notifications, Self-service support resources and actions, and more.
- 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 to simplify finding, installing enterprise apps, and providing an SSO experience across resource types.
- Horizon / Citrix – Omnissa Access can also be integrated with Omnissa Horizon 8, Horizon Cloud, and Citrix-published applications and desktops. Omnissa Access handles authentication and provides SSO services to applications and desktops.
Figure 1: User workspace delivered by Omnissa Access
To leverage the breadth of the Workspace ONE digital workspace, you must integrate Workspace ONE UEM and Omnissa Access to create a true unified app catalog for users. After integration, Workspace ONE UEM can use Omnissa Access for authentication and users will have access to native, web, SaaS, Horizon, Citrix, and ThinApp applications – all from a single app catalog on any endpoint. In addition, all the experience capabilities within Workspace ONE Intelligent Hub can be enabled for end users.
See Workspace ONE UEM Integration with Omnissa Access for more details.
Omnissa 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 Omnissa 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 Omnissa Access Connector synchronizes user accounts from Active Directory to the Omnissa 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 Omnissa Access implementation are described in the following table.
Table 2: Omnissa Access components
| Component | Description |
| Omnissa Access tenant | Hosted in the cloud and runs the main Omnissa Access service. |
| Omnissa Access Connector | Responsible for directory synchronization and virtual apps synchronization from on-premises resources such as Active Directory, Horizon, Citrix, and ThinApp to the Omnissa Access service. Also handles some authentication methods. You deploy the connector by running the Windows-based installer. |
Table 3: Implementation strategy for cloud-based Omnissa Access
| Decision | A cloud-based deployment of Omnissa Access and the components required was architected for 50,000 users. |
| Justification | This strategy provides validation of design and implementation of a cloud-based instance of Omnissa Access. |
Tenant installation and initial configuration
Because the Omnissa Access tenant is cloud-based, you do not have to make design decisions about databases, network access, or high availability. The Omnissa Access service scales to accommodate virtually any organization size.
Connectivity to the Omnissa 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.
Omnissa Access Connector
The Omnissa Access Connector can synchronize resources such as Active Directory, Horizon Cloud, Horizon 8, Citrix virtual apps and desktops, and ThinApp packages. The connector enables other typical on-premises resources such as RSA SecurID, RADIUS, and Active Directory Kerberos authentication. The connector typically runs inside the LAN and connects to the hosted Omnissa Access service using an outbound-only connection. This means there is no need to expose the connector to the Internet.
Deploying an Omnissa Access Connector provides the following capabilities:
- Synchronization with an enterprise directory (Active Directory/LDAP) to import directory users to the Omnissa Access service
- Omnissa Access Connector–based authentication methods such as username and password, 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 (single-pod brokering environment) desktops and applications
- Citrix-published desktops and applications
- ThinApp packages
Omnissa Access Connector is comprised of four microservices: the Directory Sync, Virtual App, User Authentication, and Kerberos Authentication services.
Figure 3: Microservices included in Omnissa Access Connector
Choose and deploy the correct version of the connector based on the use case and required functionality. For cloud-based architectures, using the latest version of the connector is recommended. For on-premises architectures, the connector version must be equal to or lower than the Omnissa Access virtual appliance version. You can download the connector from the Omnissa Access download page on Customer Connect.
Table 4: Omnissa Access Connector
| Version | Required functionality |
| Latest connector version | Recommended. Supports authentication, directory synchronization, and virtual apps synchronization. |
Table 5: Implementation strategy for the Omnissa Access Connector
| Decision | The latest version of the Omnissa Access Connector was deployed. |
| Justification | This strategy supports the requirements of Omnissa Access directory integration and allows a wide range of authentication methods. This connector also enables synchronization of resources from Horizon into the Intelligent Hub catalog. Horizon Cloud resources from the Horizon Cloud service or from Universal Broker are pulled directly into the Intelligent Hub catalog. |
Connector sizing and availability
Omnissa 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 Omnissa 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 Omnissa 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 Omnissa Access. And, to configure high availability for virtual apps synchronization, see Configuring High Availability for the Virtual App Service.
Sizing guidance and the recommended number of Omnissa Access Connector instances are described in the online documentation. See Omnissa Access Connector Systems Requirements.
Table 6: Strategy for scaling the Omnissa Access Connector service
| Decision | Two instances of Omnissa 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 Omnissa Access Connector.
For system requirements including network ports, see Omnissa Access Connector System Requirements. The requirements also link to knowledge base article KB68035 with the up-to-date IP addresses of the Omnissa 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 Omnissa Access Connector.
On-premises architecture
For the on-premises deployment, we use the Omnissa Access service virtual appliance. This Linux-based 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.
Resources such as Active Directory, Horizon virtual desktops and apps, and Citrix apps and desktops are synced by using a separate Omnissa Access Connector. The Omnissa Access Connector runs inside the LAN using an outbound-only connection to the Omnissa Access service, meaning the connector receives no incoming connections from the DMZ or from the Internet.
Figure 4: On-premises Omnissa Access logical architecture
Table 7: Strategy for an on-premises deployment of Omnissa Access
| Decision | An on-premises deployment of Omnissa 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 Omnissa Access. |
The implementation is separated into three main components.
Table 8: On-premises Omnissa Access components
| Component | Description |
| Omnissa Access appliance | Runs the main Omnissa Access Service. The Omnissa Access Service is a virtual appliance (OVA file) that you deploy. |
| Omnissa Access Connector | Performs directory synchronization and authentication between on-premises resources such as Active Directory and Horizon and the Omnissa Access service. You deploy the connector by running a Windows-based installer. |
| Database | Stores and organizes server-state data and user account data. |
For this reference architecture, Omnissa Access appliance version 23.09 was used. Later versions (24.07 and 24.12) are available as upgrades only; a direct installation of those versions is not supported.
Database
Omnissa 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 Omnissa 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 Omnissa Access web-based setup wizard to connect to the external database. Licensed users can use an external Microsoft SQL Server 2014, 2016, 2017, 2019, or 2022 database server to set up a high-availability external database environment. For more information, see Create the Omnissa 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 Omnissa Access System and Network Configuration Requirements.
Table 9: Implementation strategy for the on-premises Omnissa 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
Omnissa Access has been tested to 100,000 users per single virtual appliance installation. To achieve failover and redundancy, deploy multiple Omnissa Access virtual appliances in a cluster. If one of the appliances has an outage, Omnissa Access will still be available.
A cluster is recommended to contain three Omnissa Access service appliance nodes to avoid split-brain scenarios. See Recommendations for Omnissa 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 Always On availability groups, which are supported with Omnissa Access. This allows the deployment of multiple instances of Omnissa 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 Omnissa Access architecture
For more information on how to set up Omnissa Access in a high-availability configuration, see Using a Load Balancer or Reverse Proxy to Enable External Access to Omnissa Access and the Multi-site Deployment section in Omnissa Access Configuration.
For guidance on server quantities and hardware sizing of Omnissa Access servers and Omnissa Access Connectors, as well as TCP port requirements, see Omnissa Access System and Network Configuration Requirements.
Network latency
There are multiple connectivity points between Omnissa 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 Omnissa Access connections
| Source | Destination | Latency Target |
| Omnissa Access service nodes | Microsoft SQL Server | <= 4 ms |
| Omnissa Access Connector | Domain controller (AD) | <= 4 ms |
Table 11: Implementation strategy for on-premises Omnissa Access appliances
| Decision | Three instances of the Omnissa 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 Omnissa Access connectors
| Decision | Two instances of Omnissa 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 Omnissa Access service in a cluster configuration and use a third-party load balancer. Most load balancers can be used with Omnissa Access. The load balancer must, however, support long-lived connections and web sockets, which are required for the Omnissa Access Connector communication channel.
Deploying Omnissa 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 Omnissa Access appliances in the DMZ. Omnissa Access Connectors are hosted in the internal network. The connectors communicate with the Omnissa Access service nodes through the service URL using an outbound-only connection.
Figure 6: On-premises Omnissa Access load balancing and external access
In this example, the Omnissa 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 Omnissa Access but is recommended. Omnissa Access supports only one namespace; that is, the same fully qualified domain name (FQDN) for Omnissa Access must be used both internally and externally for user access. This FQDN is referred to as the Omnissa 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 Omnissa 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 Omnissa 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 Omnissa Access service node can be left using the default self-signed certificate.
Certificate Restrictions
Omnissa 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: Omnissa Access Connectors must be able to use TCP 443 (HTTPS) to communicate with the Omnissa Access service URL.
It could be beneficial to add a redirect from HTTP to HTTPS for the load balancer and for the Omnissa Access service URL. This way end users do not have to specify https:// when accessing Omnissa 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 Omnissa 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
Omnissa Access is the primary entry point for end users to consume all types of applications, including SaaS, web, Horizon virtual desktops and applications, Citrix apps and desktops, 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 Omnissa 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 Omnissa Access in a Secondary Data Center for Failover and Redundancy.
Omnissa Access consists of the following components, which need to be designed for redundancy:
- Omnissa Access appliances and the service URL
- Omnissa Access Connectors
- Database
Table 15: Site resilience strategy for on-premises Omnissa Access
| Decision | A second site was set up with Omnissa Access. |
| Justification | This strategy provides disaster recovery and site resilience for the on-premises implementation of Omnissa Access. |
Omnissa Access appliances and connectors
To provide site resilience, each site requires its own group of Omnissa Access virtual appliances to allow the site to operate independently, without reliance on another site. One site runs as the active Omnissa Access cluster, while the second site has a passive cluster group. The determination of which site has the active Omnissa Access cluster 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 by configuring traditional multi-site redundancy with a passive second cluster in Site 2, powered on and ready to handle requests upon failover.
This configuration often requires performing manual tasks to achieve failover to the second site. In this reference architecture, we explain the multi-site disaster recovery architecture, which is complex to set up and operate.
Within each site, Omnissa 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 Omnissa 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 Omnissa Access Connector servers are hosted in the internal network and use an outbound-only connection to the Omnissa Access service appliances. These connectors connect over TCP 443 (HTTPS) to the global load balancer and to the Omnissa Access service URL. It is therefore critical that the Omnissa Access Connectors be able to resolve the Omnissa Access service URL.
Table 16: Disaster recovery strategy for On-Premises Omnissa 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 Omnissa 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 replicating the Microsoft SQL database server or using native Microsoft SQL Server functionality.
Omnissa Access supports Microsoft SQL Server and its Always On availability groups feature. This allows us to deploy multiple instances of Omnissa 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.
Omnissa 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.
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 Omnissa Access architecture
For this design, Omnissa Access was configured as follows:
- It uses a hot standby deployment.
- Omnissa 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 Omnissa 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 Omnissa Access virtual appliance.
- Only the active site can service user requests.
- An active Omnissa 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 Omnissa 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 Omnissa 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 Omnissa Access appliances, creating SQL Server failover cluster instances, creating an Always On availability group, and configuring Omnissa Access appliances to point to the AGL, see the Create and Configure the Availability Group section in Omnissa 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 Omnissa 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. |
| 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. |
Prerequisites
This section details the prerequisites for the Omnissa Access configuration.
vSphere and ESXi
See the Omnissa Product Interoperability Matrices for more details about supported versions.
NTP
Your entire Omnissa Access implementation must be correctly time-synchronized. By default, the Omnissa 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 Omnissa Access Service.
Network configuration
- Static IP addresses and DNS Forward (A) and Reverse (PTR) records are required for all servers and the Omnissa Access service URL.
- Inbound firewall port 443 must be open so that users outside the network can connect to the Omnissa Access service URL load balancer.
- Other inbound ports might be required, depending on which authentication methods your use cases require.
Active Directory
Omnissa Access supports Active Directory on the Windows Server versions listed in Omnissa Access System and Network Configuration Requirements. The following directory topologies are supported:
- 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 Omnissa Access are depicted in the following diagram.
Figure 8: Omnissa Access installation and configuration steps
Omnissa Access OVA
The Omnissa Access service appliance is delivered as an Open Virtualization Format (OVF) template. For information on deploying the Omnissa Access service appliance, see Deploying Omnissa 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: Omnissa 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 Omnissa 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 Omnissa 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 Omnissa Access Appliances section in Omnissa Access Configuration.
Omnissa Access configuration
After initial setup, you can access the Omnissa Access web console. Because Omnissa Access depends heavily on the Omnissa Access service URL, it is recommended that you configure this service URL first. For more information, see Modifying the Omnissa Access Service URL. If you have issues changing the service URL, see the troubleshooting tips in Troubleshooting FQDN Updates: Omnissa 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 Omnissa Access Connectors. Now is also a good time to turn on logging to an external Syslog server.
Connector configuration
The Omnissa 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 Omnissa Access Connector, see the Omnissa Access Connector documentation.
Cluster configuration
The procedure to create an Omnissa Access cluster is described in Configuring Failover and Redundancy for Omnissa 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: Omnissa Access Operational Tutorial.
Directory configuration
Omnissa Access supports multiple directory types, including Active Directory, LDAP, and cloud-based identity providers.
To integrate with a cloud-based identity provider such as Microsoft Entra ID or Okta, you can configure Omnissa Identity Service, a platform service that enables centralized user management across Omnissa products. When Omnissa Identity Service is enabled for an Omnissa Access tenant, user provisioning and authentication are handled completely by Omnissa Identity Service, not by Omnissa Access. See the Omnissa Identity Service documentation for information. (Note that Omnissa Identity Service can be integrated only with the Omnissa Access cloud service, not with an on-premises deployment.)
Many implementations of Omnissa Access 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 Omnissa Access should have. See Managing User Attributes in Omnissa Access 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 Omnissa Access. If the user has the attribute populated and if Omnissa 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.
Omnissa Access also supports local users, which are created locally in the Omnissa Access service and not synced from an existing directory.
Service updates
Make sure all the Omnissa 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 Omnissa Access.
Application catalog
Finally, you configure application integration and publish applications in the Omnissa 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 Omnissa Access. After integration:
- Workspace ONE UEM can use Omnissa 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 Omnissa Access Integration section in Platform Integration and Setting Up Hub Services to Support Workspace ONE Intelligent Hub for more details.
Access to resources through Omnissa Access
Omnissa Access powers the Workspace ONE Intelligent Hub catalog, providing self-service access to company applications for business users. Omnissa Access is responsible for the integration of web-based SaaS applications, internal web applications, Horizon and Citrix virtual desktops and published applications, App Volumes applications, and ThinApp packages. 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 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, can be used to enhance the user experience.
The Workspace ONE Intelligent Hub app:
- Delivers a unified application catalog of SaaS, mobile, Windows, macOS, and virtual applications to the user. Through integration, Omnissa Access applications are aggregated with Workspace ONE UEM–delivered applications.
- Provides a launcher to access the apps and virtual desktops, enabling 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.
- If People Search is configured, lets users search the company’s user directory, retrieving employees’ phone numbers, email addresses, and position on the organization chart.
Figure 10: Workspace ONE Intelligent Hub
The Workspace ONE Intelligent Hub 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.
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 Omnissa Access and allow users seamless SSO access while being protected by the rich access policies within Access.
The app catalog provided by Omnissa Access includes templates with many preconfigured parameters to make federating with the SaaS provider easier. For SaaS providers, where there is no template, a wizard guides you through configuring the application and entitling users. Access supports SAML and OpenID Connect protocols for federation. 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 on Windows Desktop
Figure 13: The Intelligent Hub application catalog for end users on iPhone iOS
Horizon apps and desktops
The capability to deliver virtual apps and desktops continues to be a significant value for Workspace ONE users. Omnissa Access can be integrated with a Horizon implementation to expose the entitled apps and desktops to end users. Through the Horizon Client for native mobile platforms, access to these resources can be easily extended to mobile devices.
You must deploy the Omnissa Access Connector to provide access to on-premises Horizon resources from the Omnissa Access cloud-based or on-premises service. The connector enables you to synchronize entitlements to the service. The Horizon Cloud service can be integrated with the Omnissa Access cloud-based service directly.
Note: Omnissa 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, by using VPN services like Workspace ONE Tunnel, publishing on the Internet, and more.
Refer to Setting Up Resources in Omnissa Access (Cloud) or Setting Up Resources in Omnissa Access (On-Premises) for more details on how to add applications and other resources to the Workspace ONE Intelligent Hub catalog.
See the Omnissa 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 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, Omnissa Access, Omnissa Intelligence, Workspace ONE Assist, Horizon Cloud, 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, Horizon 8, App Volumes, Dynamic Environment Management, and more.
Additional resources
For more information about Omnissa Access, you can explore the following resources:
Changelog
The following updates were made to this guide:
| Date | Description of Changes |
| 2026-02-12 |
|
| 2025-04-04 |
|
| 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, Principal Product Specialist, Omnissa.
- Nandini Sharma, Senior Product Specialist, 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.