Workspace ONE Access Frequently Asked Questions (FAQs)

Overview

Now, more than ever, companies are investing in and enabling a digital workspace user experience. Often motivated by the flexibility and variety of supported work styles, they choose Workspace ONE UEM, Horizon, and Omnissa Access to achieve this. Omnissa Access is also being utilized more often by software-defined data center (SDDC), virtualization architectures for private, public, and hybrid clouds. If you fit into either camp, you can benefit from gaining a good understanding of the architecture of Omnissa Access so you can implement it successfully.

This Frequently Asked Questions (FAQ) asset provides advice and tips and answers to your FAQs, as well as links to additional information.

Audience

This asset is intended for IT professionals and Workspace ONE administrators of existing production environments. Both current and new administrators can benefit from using this asset. Familiarity with networking and storage in a virtual environment is assumed, including Active Directory, identity management, and directory services. Knowledge of additional technologies such as Omnissa Access and Workspace ONE UEM is also helpful.

Deployment

What are the basic components of Omnissa Access?

The key components of the access solution are the service, the service URL, and the Connector.

• Service. The service component is visible via the Omnissa Access web portal. End users use the portal to access applications and desktops, and administrators use it to manage access for their end users. The service handles several authentication methods and is available as both hosted/SaaS and on-premises. The Omnissa Access service can be seen as your identity provider (IdP) as well, although it is actually more than that because it includes the web portal. The service generates and creates SAML Assertions, OpenID Connect identity tokens, and the OAuth2 access tokens.
• Service URL. Also referred to as the Service FQDN, the fully qualified domain name (FQDN) is what you type into the browser to access Omnissa Access. This URL is used in the SAML Issuer ID, as well as by Connectors to find their respective clusters. Although not technically a component, it is included in this list because of its importance for a successful implementation, and the fact that Omnissa Access only supports one name space (one FQDN). Note: Do not confuse the Service URL with the local FQDN hostname of a local node, applicable only for the on-premises version.
• Connector. The Omnissa Access Connector plays a part in synchronizing and enabling internal resources into the service. This includes synchronizing Active Directory (AD) users, and handling authentication methods that typically happen on premises, such as AD Password, RSA SecureID, AD Kerberos, and RADIUS. The Connector is also responsible for synchronizing Horizon and Citrix entitlements into the catalog that is hosted on the service.

What are the pros and cons of cloud-hosted vs on-premises?

The Omnissa Access service is offered in two different methods of deployment: cloud-hosted and on-premises.

• Cloud-Hosted Service. This option is serviced and handled as a software-as-a-service (SaaS). That means continuous development. New code is checked in daily, and features sit behind feature flags, so updates do not require any downtime. You cannot choose your own FQDN. For example, in a name like workspaceoneaccess.com, your company name would precede it, such as companyname.workspaceoneaccess.com. This option stores Personally Identifiable Information (PII) in the cloud. At minimum, this includes the username, which is a required field. For full functionality, however, it would also include email addresses, first and last names, User Principal Names (UPNs), and so on. Active Directory Passwords cannot be extracted from Active Directory, so they are not stored in the Service.
• On-Premises Service. This option stores Personally Identifiable Information (PII) locally. For a highly regulated business that prefers to avoid storing PII in the cloud, the on-premises version of Omnissa Access is recommended. The PII is hosted on-premises within your own firewall, and you can freely choose your FQDN, such as login.companyname.com, which is easier for end users to remember. This means you hold the responsibility for maintenance, scheduling downtime for updates, and so on.

How does the deployment method impact integration capabilities?

Just because one component is on-premises, does not mean all components must be. Both the on-premises service and the cloud-hosted service can connect to either on-premises or cloud-hosted integrations. You can integrate Omnissa Access with Horizon 7 on-premises or in the cloud, Workspace ONE Unified Endpoint Management (UEM) on-premises or in the cloud, and so on.

Omnissa Access	Horizon on-premises	Horizon Cloud Service	Workspace ONE UEM on-premises	Workspace ONE UEM hosted
Hosted	Supported	Supported	Supported	Supported
On-premises	Supported	Supported	Supported	Supported

Is there feature parity between on-prem and cloud?

No, there will never be feature parity between the on-premises and the cloud-hosted versions of Omnissa Access. It would be impossible to release an on-premises version on a daily cadence. Although new features are not turned on every day, updates are checked in on a daily basis which constantly improve the cloud service. The on-premises version release cycles happen less frequently and thus receive new functionality at a slower rate than the cloud-hosted version. Although we strive to keep the two versions as close as possible, the SaaS version is always ahead of the on-premises version.

What’s the difference between the Service URL and the Service Node FQDN?

The Service URL is the FQDN that end users enter in the address field in the browser to access the web portal of the Service. If you deploy on-premises, you are in charge of the FQDN.

If you deploy a cluster, the Service Nodes will have local host names (the minimum is 3 nodes per cluster). And you will provide the Service FQDN URL, owned by a load balancer, for end users.

Note: When deploying Omnissa Access on-premises, it is important to take advantage of the Change FQDN option when you deploy your first node. Immediately after deploying the first node, before you integrate Connectors or create clusters or Connector Activation Codes, navigate to the Appliance Settings, and select Change FQDN. Enter the new FQDN of the local machine to be used for connectors and end users. This identifies your implementation, and end users will use it to access your service. When you change that, the service immediately presents itself with this FQDN. If issues changing the FQDN arise, see Trouble Changing the FQDN.

This must be done using a trusted certificate because the only way to communicate is over HTTPS. If you are hosting the FQDN outside of your service node, such as in a load balancer, it is recommended that you terminate SSL/TLS on the load balancer. You can keep the self-signed certificate on the node because the node is not touched directly, only through the load balancer.

What if I want everything in a single Linux appliance?

In previous versions, such as version 3.3 for example, a Connector was embedded. For that reason, SDDC components such as those in NSX-T Data Center are based on version 3.3, which keeps the footprint to a minimum. End-user computing use cases make use of new versions, such as version 19.03, in which the Connector has been separated out, but the functionality is the same.

How do you implement Omnissa Access on-premises?

You must deploy the Service Node on premises, which is different from the cloud-hosted version.

• Service Node. You deploy the Service Node on-premises, which is the major difference from the cloud-hosted version.
• FQDN. The Service URL must be on-premises, or at least handled on-premises, as well. Omnissa Access depends heavily on DNS, and requires both A Records and PTR Records.
• Database. The Microsoft SQL Server database is the only database supported by Omnissa Access. The exception is when you are implementing for SDDC, in which case, the built-in vPostgres database is supported. For clustering, however, an external Microsoft SQL database is required.
• Time Sync. Omnissa Access depends heavily on time and must be time-synched with the rest of the infrastructure. SAML is sent back and forth between the Connector and the Service, and SAML typically have a Time-To-Live of about 5 minutes. However, it is not 5 minutes in both directions—SAML has only 30 seconds from future messages. That means that if one system is running 1 minute ahead of time, issues will occur.
  
  Here is a typical basic implementation of Omnissa Access on a single node.

In this example, you might decide to deploy the Service URL as the node’s local FQDN. The machine running the Service itself has the FQDN that is used for client access, as well.

However, this presents a problem because you are now locked in. You cannot change this configuration, because you cannot change the host name of the machine. This limits you, because if you want to create a cluster at some time in the future, deploying the Service URL as the local host name is not a good idea.

You can place the Omnissa Access in the DMZ as shown in the above diagram, a typical end-user computing use case where you want your users to have external access to Omnissa Access. You can deploy Access within your LAN if you do not require external access or you will use VPN for external access.

What is a managed device?

In Omnissa Access, a “managed” device is determined by a successful mobile SSO or certificate- based authentication. In scenarios when Omnissa Access is sending the Device SSO Response in the SAML Response (for example, Okta/Ping Integrations), the UDID (aka Device ID) must be provisioned by Workspace ONE UEM as part of the SAN attributes on the certificate.

For more details, see Omnissa Access: Best Practices in Policy Management.

What is the Omnissa Access User Engagement Dashboard?

The Omnissa Access console provides user and device analytics on the User Engagement Dashboard which allows you to:

• Monitor device-level usage analytics on a per-user and per-app basis.
• Specify audit events and generate reports for a configurable time period.
• Audit events and include time, date, and identity of administrative changes to permissions and app access.

Authentication and Connection

What does the Connector do?

Typically, the Connector is used in both on-premises and cloud-hosted implementations to synchronize users into Omnissa Access.

There are alternatives. But the Connector performs the full functionality of user replication. The Connector can handle synchronization of Horizon and Citrix entitlements, and ties to local authentication methods such as RSA SecurID, RADIUS, Active Directory Kerberos, and Active Directory username/password.

Does Omnissa Access support multi-tiered, multi-forested directories?

Yes, Omnissa Access can integrate the Omnissa Access service with an Active Directory environment that consists of a single Active Directory domain, multiple domains in a single Active Directory forest, or multiple domains across multiple Active Directory forests.

How do you verify device compliance?

In order for Omnissa Access to check for device compliance, a valid certificate with the device ID (in the SAN attributes) needs to be provisioned to the device. Device compliance can only be used in conjunction with mobile SSO or certificate-based authentication because this is currently the only way for Omnissa Access to know what the device UUID is in order to validate device compliance.

For more details, see Omnissa Access: Best Practices in Policy Management.

Which authentication methods does Omnissa Access support?

A variety of authentications methods are supported. The Connector handles some authentication methods, but others can be handled by the Service component itself.

Authentication Methods	Description	Requires Connector
Password (cloud deployment)	For password (cloud) authentication, users are synced from your enterprise directory and are authenticated directly against your enterprise directory. You can select the option to set up password authentication when you configure the directory. You can also set up password authentication later from the Enterprise Authentication Methods page in the Omnissa Access console.	Yes - Omnissa Access Connector
RSA SecurID (cloud deployment)	To use the RSA SecurID (cloud deployment) authentication method with Omnissa Access, the Omnissa Access server is configured as the authentication agent in the RSA SecurID server. RSA SecurID authentication requires users to use a token-based authentication system. RSA SecurID is an authentication method for users accessing Omnissa Access from outside the enterprise network.	Yes - Omnissa Access Connector
RADIUS (cloud deployment)	RADIUS (cloud deployment) authentication provides two-factor authentication options. You set up a RADIUS server that is accessible to the User Auth service on the connector. When users sign in with their user name and passcode, an access request is submitted to the RADIUS server for authentication.	Yes - Omnissa Access Connector
Kerberos Auth	Kerberos authentication provides users who are successfully signed in to their Active Directory domain, access to their apps portal without additional prompts for their credentials. Kerberos authentication uses Integrated Windows Authentication (IWA).	Yes - Omnissa Access Connector
Certificate (cloud deployment)	Certificate-based authentication can be configured to allow clients to authenticate with certificates on their desktop and mobile devices or to use a smart card adapter for authentication. Certificate-based authentication is based on what the user has and what the person knows. An X.509 certificate uses the public key infrastructure standard to verify that a public key contained within the certificate belongs to the user.	No
Mobile SSO (for Android)	Mobile SSO for Android is a certificate proxy authentication used for single sign-in authentication for Workspace ONE UEM-managed Android devices. A proxy service is set up between the Omnissa Access service and Workspace ONE UEM to retrieve the certificate from Workspace ONE UEM for authentication.	No
Mobile SSO (for iOS)	Mobile SSO for iOS authentication is used for single sign-on authentication on Workspace ONE UEM-managed iOS devices. Mobile SSO for iOS authentication uses a Key Distribution Center (KDC) that is part of the Omnissa Access service.	No
Mobile SSO for Apple (Cloud only)	Mobile SSO for Apple authentication is used for single sign on of Workspace ONE UEM-managed iOS devices and will replace the KDC based Mobile SSO for iOS method. It implements the certificate authentication method together with Apple SSO extension settings.	No
FIDO2 Authentication (Cloud only)	FIDO2 provides strong phishing resistant passwordless authentication using cross-platform(e.g. USB keys) or platform(e.g. TouchID) than can be preregistered by an admin or enrolled by a user.	No
Password with Workspace ONE UEM	The AirWatch Cloud Connector can be integrated with the Omnissa Access service for user password authentication. You configure the Omnissa Access service to sync users from the Workspace ONE UEM directory.	Yes - AirWatch Cloud Connector
Verify (Intelligent Hub) (Cloud only)	Verify (Intelligent Hub) can be used as the second authentication method when Multi-Factor authentication is required. It requires integration with Workspace ONE UEM, Hub Services and UEM-managed device.	No
Authenticator App (TOTP)	Any TOTP (RFC 6238) conform app can be registered and will Time-based One_Time passcodes to be used as second authentication factor when multi-factor authentication is required.	No
Duo Security (Cloud only)	Duo Security integrated with the Duo web SDK to enable the use of DUO as second authentication factor when Multi-Factor authentication is required.	No
Token Auth Adapter (Cloud only)	Token Auth Adapter is used for Day Zero Onboarding generating a one-time use access token, magic link to onboard pre hires.	No
UEM Token (Cloud only)	UEM Token allows for the use of UEM device registration tokens to authenticate the user/device at the time of enrolment of a device.	No
Shift-based authorization (Cloud only)	Shift-authorization allows the creation of access policies to manage the access to application based on timekeeping systems integrated with Hub Services	No
Risk Score Based Authentication (Cloud only)	Risk Score based authentication leverages the integration with Workspace ONE Intelligence to allow to step up authentication in policies based on User Risk Score or Login Risk Score	No

How does the communication flow work?

Let’s say you have decided to implement cloud-hosted Omnissa Access. You have a local component, the Connector, which connects to Horizon on-premises and your local Active Directory. The Connector is hosted on a Windows machine. You install it, and the first thing it asks for is an activation code. If you decode (it is Base64 encoded) it, it reveals the URL of your service node. First thing, the Connector reaches out and pairs itself to the service with an outbound connection. The session is established from within your network, out to the Service. The connection is outbound from your network to the Service, but is bi-directional. The Connector can send messages to the Service and the Service can call on the Connector at any time to perform actions, such as authentication or synchronization.

From the point of view of the firewall, you must allow the outbound connection only, without regard to the inbound connection. You very rarely need to expose your Connector externally and in the majority of situations, you can rely on this outbound connection. If you have used Workspace ONE UEM (formerly AirWatch), this will be familiar to you because it is similar to how ACC communicates.

How does the authentication flow?

By default, the traditional, regular authentication flow is activated when a user connects to the Service. When you tie a Connector to the Service, you specify the Active Directory that the Connector is synchronizing. Automatically, the Connector configures itself to handle authentication with username and password into the system, based on these Active Directory users. Hopefully, you will choose a more modern and stronger method of authentication, such as certificate-based authentication. However, the default is that, if you have just deployed the Connector and integrated Active Directory, you have AD username and password capability into the system. This is the flow:

The user accesses the Service node, and the Service knows only the FQDN of your Connector. So, it redirects the user to the Connector, which displays a username and password prompt to the user. The user authenticates, and then gains access into the Service.

Example

Let’s put this into practice, now that your users are within your LAN. As shown above, the user tries to connect with the SaaS instance of Omnissa Access, which knows only the FQDN of the Connector. It passes the FQDN of that Connector to the client. The user’s web browser connects to it, which is possible because it is in the LAN, authenticates, and then is passed back and authenticated into the system.

This is often how a proof of concept looks at first glance. You are onsite, in the LAN, everything is set up and operates as designed. The problem is, however, when you go home and try to authenticate from outside the firewall. You connect to the cloud instance, and get redirected to the local FQDN. And then you receive the following error message.

Omnissa Access appears to be broken; however, this is Standard Mode, the default behavior. Therefore, it is important to know how to configure the capability to authenticate from an external location. You can do this by configuring Outbound Mode, instead of accepting the default Standard Mode.

With Outbound Mode, the user connects to the Service. The Service displays the username and password, and sends the credentials to the Connector. The Connector validates them, sends the OK to the Service, and now the user has secure access from outside the firewall.

How does an on-premises connection work?

As shown in the following diagram, all communication goes to the Service URL. Both internal and external users connect directly to the Service URL.

You could set up a split DNS infrastructure with two zones for the same domain, one used by the internal network and the other by the external network. It is possible to avoid using split DNS. However, this would require internal users to make a round trip on your external interface in the firewall, and then come back into the network, creating unnecessary traffic flow. Even though the web service does not generate a huge amount of traffic, it is avoidable, and recommended that you implement a split DNS. You can point internal users to the internal IP address, and point external users to your firewall.

You can place the SQL database either in the DMZ or in the LAN. It is important to make sure that the Omnissa Access Service Node has full and low latency access to your database server.

Configuration

How do you configure Outbound Mode?

Configuring Outbound Mode is not immediately logical, so it is described here in detail.

When you have deployed Omnissa Access, the administration console includes a couple of identity providers. One of them is Built-in, the service’s own authentication method. The authentication methods within the Service are handled in the Built-in identity provider. You can see the Built-In label in the upper left:

You must add the functionality of the Connector into the Built-In identity provider, as follows:

• In the admin console, navigate to the Built-in identity provider.
• Specify domain and network ranges.
• Import Connectors.

When the Connectors are imported, authentication methods must be activated. In the following example, we have only one, which is Password (cloud deployment).

If you use the password authentication method in the Built-in identity provider, it defaults to the name Password (cloud deployment), whether your implementation is cloud-based or on-premises. This name just indicates that the outbound mode is being used to connect.

After setting up the Built-In identity provider as described above, go into the Access policies to make sure that you’re using the Password (cloud deployment) instead of the default authentication method, simply called Password. If you have Password in the field below, the client is redirected to the Connector. In other words, it does not work if you haven’t externalized your Connectors.

If you choose Password (cloud deployment), the service will collect username and password, and send it using the communication channel to the Connector.

How can I future-proof my basic on-premises implementation?

It is highly recommended that you separate the Service URL from the Node FQDN. This is the local host name of the Linux appliance itself. If you do this, you can freely change or move the Service URL. You cannot change the host name because encryption keys are based on it. Even in a minimum implementation where you have only one Service Node and are not planning high availability, it is still recommended that you have something else own the Service URL because of flexibility in the future. The following diagram shows the communication flow in this case:

The Connector connects to a load balancer, which load balances only one node, but still acts like a reverse proxy. So, it owns the certificate and the session. Internal users connect via the load balancer, and external users connect via the firewall and load balancer.

This might look similar to the flow depicted earlier, but there is a slight difference. The Connector not only connects to the Service URL. They also connect directly to the Node FQDN, the local machine name. This is a common mistake that is often overlooked. It is important to make sure that the Connector can internally resolve that DNS name.

How can I build availability for an on-premises implementation?

The following diagram depicts a full-blown, high availability implementation, where the Service Nodes is placed in the DMZ, with a load balancer. Notice the required 3 nodes in a cluster, a minimum implementation in a typical end-user computing use case. For more information on how to implement high availability and disaster recovery, see the Workspace ONE Reference Architecture.

How do I use network ranges?

Network ranges in Omnissa Access can be used to separate out your policies. Depending on which network they are coming from, you can define specific policies. Many Omnissa Access tenants are cloud based within a Omnissa Access data center – and network range detection will see the device’s external IP. Omnissa Access on-premises customers can also use private IPs within network range detection. However, any of these packets crossing Internet boundaries – more specifically through Internet routers or proxies – will have the X-Forwarded-For header either stripped and potentially replaced as public routers and proxies will remove all X-Forwarded-For headers containing private IP addresses per Internet Protocols (Per RFC 7239).

For more details, see Omnissa Access: Best Practices in Policy Management.

Policy Management

What is policy management?

This diagram depicts a high-level map of policy management.

When you set up and configure your policies, keep this diagram in mind:

• Authentication Methods on an Access Policy are tied to an IDP Instance (either a built-in IDP, SAML, OIDC or Omnissa Access)
  • If you are doing Mobile SSO but Mobile SSO is not selected in your IDP instance, then your authentication will fail.
• IDP Instances are linked to one or more Directory Instances
  • If your directory where the users are created in Access are not selected in the IDP Instance, your authentication methods will fail.
• IDP Instances are linked to one or more Network Ranges
  • If the users are authenticating from a network range that is not selected in the IDP Instance, your authentication methods will fail.

If any link (as noted in the diagram) is broken your authentication will fail.

For more details, see Omnissa Access: Best Practices in Policy Management.

How are policies evaluated?

Omnissa Access policies are evaluated from top to bottom. The policy will stop at the first match. In the following example,  a device type of Web Browser will prevent the policy engine from reaching macOS or Windows 10 because it comes ahead in the processing order.

For more details, see Omnissa Access: Best Practices in Policy Management.

What is a fallback authentication mechanism?

Omnissa Access has a very flexible policy engine that allows you to specify an authentication method that can be used in case a previous authentication method fails. 

However, in Omnissa Access, fallback authentication mechanisms serve multiple purposes depending on the configuration:

• Primary Authentication Failures
• Allowed Authentication Methods used in third-party IdP
• Allowed Authentication Methods used to validate a session token
• Step-up authentication for Device and Login Risk Score

The next questions in this section will address these configurations.

For more details, see Omnissa Access: Best Practices in Policy Management.

What is a primary authentication failure?

The use of an authentication method if the preceding authentication method fails is the most common use of fallback mechanisms.  In this scenario, when a primary authentication such as Mobile SSO is used (which will tell us if a device is managed) and fails (meaning the device is unmanaged or potentially managed but not compliant) we can configure another option that includes an alternative authentication plus MFA:

By configuring a fallback mechanism for Mobile SSO and Device Compliance, we are allowing unmanaged and non-compliant devices (or managed but not compliant) to access the applicable resources if they can successfully complete the Password + MFA that is defined in the fallback.

It’s very important that you are aware that when configuring a fallback mechanism for Mobile SSO or Certificate Authentication that you are potentially allowing unmanaged and non-compliant access to your applications.

The following primary authentication methods support using a fallback:

• Mobile SSO (iOS and Android)
• Certificate Authentication
• SAML (only if the SAML IDP supports a failure notification back to Omnissa Access)

The following secondary authentication methods support using a fallback:

• Verify (Intelligent Hub)
• Device Compliance (with Workspace ONE UEM)
• Login Risk Score

Let’s use the following example: If you had a policy such as Password (Cloud Deployment) with a fallback of a third-party IdP. A fallback to the third-party IdP will never happen as Password (Cloud Deployment) does not support having a fallback. There is one exception to this rule, Password (Local Directory) can be used as a fallback for Password (Cloud Deployment) to authenticate System Domain users.

For more details, see Omnissa Access: Best Practices in Policy Management.

What are the allowed authentication methods used in third-party IdP?

This depends for IDP or SP initiated authentication flows. When Omnissa Access receives the SAML Response from a third-party identity provider (IDP initiated), it includes an “AuthNContextClassRef” to tell Omnissa Access how the user was authenticated at the third-party identity provider. Omnissa Access needs Authentication methods for each possible AuthNContextClassRef that the IdP sends.

As an example, when integrating with Microsoft Azure AD, it is common for Azure to send any of the following:

• X509, MultiFactor
• urn:oasis:names:tc:SAML:2.0:ac:classes:Password
• urn:federation:authentication:windows

In the third-party IdP configuration in Omnissa Access, you must define each of these SAML Authentication Methods/Context or just configure urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified which will accept any method used by the third-party IdP:

For the scenario where the authentication with the third-party IDP is intiated from Omnissa Access (SP-initiated) we include configured authentication method in the AuthNContextClassRef send in the AuthN request to the third-party IDP. Make sure it matches with the one provided from the third-party IDP. Here you can run into issues again, especially with Azure AD if the user already is signed in with another method as we cannot configure the forceAuthn=true part of the AuthN request to force a new authentication for which Azure AD could honor the  requested authentication method. Azure AD will try to match the authentication method to the existing session with the user and stop with the error AADSTS75011 mismatch with existing method 'X509, MultiFactor for example if the user used the PRT, Hello4Business or MFA before. Here again best use the AuthNContextClassRef urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified as authentication method in the access policy configured for Azure AD.

For more details, see Omnissa Access: Best Practices in Policy Management.

What are the allowed authentication methods used to validate a session token?

When authenticating to Omnissa Access, a session cookie or OAuth2 token is generated. Inside this session cookie/token, you can see the method of authentication that was used at the time of cookie creation (for example, “urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient”).

Omnissa Access compares the previously used authentication method to see if it matches ANY of the allowed authentication methods for the configured application. If it matches, there will be no further authentication (as long as it is within the allowed session time).

Here are examples of this use case in action.

Example 1:

• User logs into Omnissa Access using FIDO2 Authentication.
• User clicks on Salesforce Application.
  • Salesforce has a Policy: Primary Authentication=Certificate Authentication.
• Result: User is Prompted for Certificate Authentication.
• Result: User is Granted Access.

Example 2:

• User logs into Omnissa Access using FIDO2 Authentication.
• User clicks on Salesforce Application.
  • Salesforce has a Policy: Primary Authentication=Certificate Authentication and Fallback: FIDO2 Authentication.
• Result: User is Granted Access because the previously used authentication method (FIDO2 Authentication) matches one of the fallbacks.

For more details, see Omnissa Access: Best Practices in Policy Management.

How do I configure step-up authentication for device and login risk score?

If you are using User Risk Score or Login Risk Score, in the configuration of the Authentication Method you will define the appropriate action based on the result of the risk score calculation.

In your Authentication Policy, the fallback mechanism is considered your “Step-Up Authentication”. So, your policy would like something like this:

In the previous policy, when Certificate Authentication is Successful, but Login Risk Score is coming back as Medium or High, it will fall back (or in this case Step-Up) to the next policy rule. We still must keep Certificate Authentication as the primary along with my MFA as the secondary.   Just keep in mind with this policy, if Certificate Authentication is not successful, you will return an Access Denied Error.  You might potentially require another fallback if you want to provide a “real” fallback.

For more details, see Omnissa Access: Best Practices in Policy Management.

What is Omnissa Access conditional access?

Omnissa Access conditional access policies allow you to control access to corporate apps and resources based on designated criteria such as:

• Organization group inherited from AD.
• Dynamic user groups maintained within the admin console.
• Device ownership (corporate-owned versus personal device).
• Device usage (mobile versus desktop).
• Network / IP range.

Some authentication methods that you can specify are:

• Device compliance.
• Risk score.
• Mobile SSO.

Device Types and Platform Support

What is a device type?

A device type refers to a grouping or categorization of devices based on common identifiers such as the operating system or based on action, such as enrolling your device into Workspace ONE UEM. In most cases, you can match multiple device types, depending on the context. 

The next few questions will walk through some of the device types available in Omnissa Access SaaS environments and how ordering your policy rules are critical to ensure the integrity of your policy definition.

Note: On-premises environments might not have all the device types listed in this section.

For more details, see Omnissa Access: Best Practices in Policy Management.

What device types and platforms does Omnissa Access support?

Device types for SaaS environments and their supported platforms include:

Device Type	Workspace ONE Intelligent Hub	Windows 10 AAD	Windows 10	iPhone	iPad	Android	macOS	Chrome OS	Linux
Device Enrollment	✅
Windows Enrollment*		✅
iOS				✅	✅ SaaS only
iPad					✅ SaaS only
Android**						✅
Windows 10			✅
macOS***					✅		✅
Chrome OS								✅ SaaS only
Linux									✅ SaaS only
Web Browser****			✅		✅	✅	✅	✅	✅
All Device Types / Any****			✅	✅	✅	✅	✅	✅	✅

*Supports Windows 10 Azure Active Directory (AAD) Join OOBE and Settings

**Supports Android Enterprise, Android Legacy, Samsung Knox, Rugged

***Supports iPad on-premises only

****Supports iOS/iPad only if the policy rule is above an iOS/iPad rule, supports Android only if the policy rule is above an Android rule

The Apps on Workspace ONE Intelligent Hub device type is supported and discussed in the next question.

For more details, including unsupported platforms for each device type, see Omnissa Access: Best Practices in Policy Management.

Describe the Apps on Workspace ONE Intelligent Hub device type

The Apps on Workspace ONE Intelligent Hub device type is not used to authenticate users into the Workspace ONE Intelligent Hub application.  

The purpose of this device type is to provide a seamless user experience when launching applications from the Workspace ONE Intelligent Hub. This device type is used to validate your existing access token (from the Intelligent Hub) when you click on a Web or SAAS application in the Intelligent Hub application.  

When you enroll your device with the Workspace ONE Intelligent Hub, you receive an OAuth2 Token from Omnissa Access. This access token contains both a timestamp and the method of authentication used at the time of enrollment (or re-authentication).

When you launch an application from the Intelligent Hub, Omnissa Access will:

• First, compare the method of authentication last used into the Intelligent Hub (either from Enrollment or Re-Authentication) to see if it matches any authentication methods listed on the Apps on Workspace ONE Intelligent Hub policy.
• Secondly, it will compare the timestamp last used to authenticate into the Intelligent Hub to see if its within range of the “Re-authenticate After” setting in the Apps on Workspace ONE Intelligent Hub policy.

What is happening in this policy evaluation? When you first enrolled your device, you probably used a Password + MFA or you used a third-party IdP. After successful enrollment, a Mobile SSO profile was pushed to your device for future authentication challenges.

The authentication token for the Workspace ONE Intelligent Hub has a default session lifetime of 90 days. This means that you can go up to 90 days before re-authenticating into the Intelligent Hub again (using the Mobile SSO profile that was configured). The default configuration does have a 10-day idle TTL which will require the user to re-authenticate again if they have been idle for 10 days. 

For more details, see Modifying the WS Intelligent Hub Timeouts.

The following screenshot depicts a common Apps on Workspace ONE Intelligent Hub policy rule:

Let’s assume during enrollment, that you authenticated using a Password (cloud deployment) + DUO Security. When a SAAS/Web application is launched from the Intelligent Hub, Omnissa Access will match your Password (cloud deployment) authentication method with one of the fallbacks listed and satisfy the first check mentioned previously.

The next validation is with the session time. How long ago did you authenticate into the Intelligent Hub? Based on default settings, that could have been up to 90 days (or 2160 hours) ago. The policy rule will never force a re-authentication (and trigger Mobile SSO) if you are within 2160 hours. To further illustrate this example, if you reduced the setting for “Re-authenticate after” to 8 hours, you will be prompted to re-authenticate on every app launch starting from 8 hours after enrollment because your session start time is based on when you last authenticated into the Intelligent Hub Application and not the last time you authenticated for an application launch. Without an Apps on Workspace ONE Intelligent Hub policy, the user will be challenged with Mobile SSO on every application launch from the Intelligent Hub. Fortunately, Mobile SSO provides a great user experience and this is all transparent to the user.

For more details, see Omnissa Access: Best Practices in Policy Management.

Access Policy Recommendations

What are your recommendations for access policies?

This section discusses the recommended approach to setting up your Access Policies. Your individual authentication methods might be different based on your own use cases and security requirements.

Disclaimer: The recommendations and guidelines posted here are based on feedback provided by customers and other internal/external professionals. They are offered as guidelines for your reference only and are not intended to represent the only approach to any particular use case. The guidelines posted here should not be construed as security advice, and users should seek appropriate security or other professional advice to address specific use cases and circumstances.

Access Policy	Purpose
Default access policy set	• Workspace ONE Hub Enrollment • Workspace ONE Hub Re-Authentication • Omnissa Access Portal
Workspace ONE UEM	• Workspace ONE UEM Web Enrollment • Workspace ONE UEM DEP Enrollment
High-security applications	• Applications that will require higher security (potentially Device Compliance, MFA, Login Risk)
Low-security applications	• In this access policy, we will allow fallbacks for potentially less secure authentication methods such as Password. Third-party IdP can also be used.
Okta/Ping/ADFS low security	• In this access policy, we will allow fallbacks for potentially less secure authentication methods such as Password. Third-party IdP can also be used.
Okta/Ping/ADFS medium security	• In this access policy, we will configure Mobile SSO or Certificate-Based Authentication without any fallbacks. • Original Okta Device Trust.
Okta/Ping/ADFS high security	• In this access policy, we will configure Mobile SSO or Certificate-Based Authentication + Device Compliance without any fallbacks.
Horizon/Citrix	• This is for your virtual apps.

For more details, see Omnissa Access: Best Practices in Policy Management.

Define a sample default access policy set

Your “Default Access Policy Set” will be used for the following purposes:

Workspace ONE Hub Enrollment

Workspace ONE Hub Re-Authentication

Omnissa Access Portal

In Workspace ONE UEM, the configuration that is being used is set in Groups and Settings > All Settings > Devices & Users > General > Enrollment:

Device Type	Authentication Methods
Device enrollment	This authentication method should include a Password + MFA. Alternatively, you can use a third-party IdP that includes MFA.
Apps on Workspace ONE Intelligent Hub	This device type is used to transfer your session from the Workspace ONE Intelligent Hub to seamlessly access your SAAS applications. We recommend using this device type on your Low Security Application Policy.
All device types (ANY)	If you are enabling FIDO2 Authentication, you should set up your policy rule here for registering your FIDO2 Authenticators by enabling the Registering FIDO2 Authenticator switch. Select your required authentication method to register your FIDO2 device.
iOS	This authentication policy should use Mobile SSO. If you want to allow a fallback for unmanaged devices, then you can choose a fallback authentication method. This will only get them into the Omnissa Access Portal or Hub Application.
Android	This authentication policy should use Mobile SSO. If you want to allow a fallback for unmanaged devices, then you can choose a fallback authentication method. This will only get them into the Omnissa Access Portal or Hub Application.
macOS	Your MacOS Policy would ideally be configured with Certificate Based Authentication. If your MacOS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Windows 10	Your Windows 10 Policy would ideally be configured with Certificate Based Authentication. If your Windows 10 devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Chrome OS	Your Chrome OS Policy would ideally be configured with Certificate Based Authentication. If your Windows 10 devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Linux	Your Linux Policy would ideally be configured with Certificate Based Authentication. If your Windows 10 devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Web browser	This can be used as catch all for all Desktop platforms if they all share the same policy setup

For more details, see Omnissa Access: Best Practices in Policy Management.

Define a sample Workspace ONE UEM access policy

Your “Workspace ONE UEM” will be used for the following purposes:

• Workspace ONE UEM Web Enrollment
• Workspace ONE UEM DEP Enrollment
  • DEP Enrollment with Custom Enrollment Enabled and Authentication ON
  • DEP Enrollment with Custom Enrollment Disabled and Authentication OFF (Staging)

In Workspace ONE UEM, the configuration that is being used is set in Groups and Settings -> All Settings -> System -> Enterprise Integration -> Directory Services:

This also requires the AirWatch application to be configured in Omnissa Access:

Device Type	Authentication Methods
ANY	Given that this policy is used for web enrollment and DEP enrolment flows, you should make this policy rule similar to the Device Enrollment policy rule in the default policy.

For more details, see Omnissa Access: Best Practices in Policy Management.

Define a sample High Security Applications access policy

Your “High Security Applications” will be used for the following purposes: Applications that require higher security (potentially Device Compliance, MFA, Login Risk).

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO and Device Compliance. We do not recommend any fallbacks for your high security applications.
Android	This authentication should use Mobile SSO and Device Compliance. We do not recommend any fallbacks for your high security applications.
macOS	Your macOS policy would ideally be configured with Certificate Based Authentication + Device Compliance. We do not recommend any fallbacks for your high security applications. If you want to use FIDO2 on your high-security applications, we recommend you also include Certificate Authentication + Device Compliance in your policy rule.
Windows 10 enrollment	If you are doing Azure AD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy, use a third-party IdP or smartcards for certificate authentication. Note: This is required if the Office 365 Web App is included in this policy.
Windows 10	Your Windows 10 Policy would ideally be configured with Certificate-Based Authentication + Device Compliance. We do not recommend any fallbacks for your high-security applications. If you want to use FIDO2 on your high-security applications, we recommend you also include Certificate Authentication + Device Compliance in your policy rule.
Chrome OS	Your Chrome OS Policy would ideally be configured with Certificate-Based Authentication + Device Compliance. We do not recommend any fallbacks for your high-security applications. If you want to use FIDO2 on your high-security applications, we recommend you also include Certificate Authentication + Device Compliance in your policy rule.
Linux	Your Linux Policy would ideally be configured with Certificate-Based Authentication + Device Compliance. We do not recommend any fallbacks for your high-security applications. If you want to use FIDO2 on your high-security applications, we recommend you also include Certificate Authentication + Device Compliance in your policy rule.

For more details, see Omnissa Access: Best Practices in Policy Management.

Define a sample Low Security Applications access policy

Your “Low-Security Applications” will be used for the following purposes:

• Applications that don’t require management or don’t require a high level of assurance.

Device Type	Authentication Methods
Apps on Workspace ONE Intelligent Hub	This device type is used to transfer your session from the Hub Application to Omnissa Access. You need fallbacks for all possibilities: Mobile SSO (iOS) Mobile SSO (Android) Certificate Authentication SAML (Third-party IdP)) Password Authentication Session time-out should also be set accordingly.
iOS	This authentication should use Mobile SSO. If you want to allow a fallback for unmanaged devices, you can choose a fallback authentication.
Android	This authentication should use Mobile SSO. If you want to allow a fallback for unmanaged devices, you can choose a fallback authentication.
macOS	Your macOS policy would ideally be configured with Certificate-Based Authentication. If your macOS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Windows 10 enrollment	If you are doing AAD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a third-party IdP. Note: This is required if the Office 365 Web App is included in this policy.
Windows 10	Your Windows 10 Policy would ideally be configured with Certificate Based Authentication. If your Windows 10 devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Chrome OS	Your Chrome OS Policy would ideally be configured with Certificate Based Authentication. If your Chrome OS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Linux	Your Linux Policy would ideally be configured with Certificate Based Authentication. If your Linux devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Web browser	This can be used as catch all for all Desktop platforms if they all share the same policy setup

For more details, see Omnissa Access: Best Practices in Policy Management.

Define a sample Okta/Ping/ADFS Low Security access policy

Your “Low Security Applications” will be used for the following purposes:

• Applications that don’t require management or don’t require a high level of assurance.

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO. If you want to allow a fallback for unmanaged devices, you can choose a fallback authentication. If you are sending the failure notification back to Okta/PING, do not configure a fallback.
Android	This authentication should use Mobile SSO. If you want to allow a fallback for unmanaged devices, you can choose a fallback authentication. If you are sending the failure notification back to Okta/PING, do not configure a fallback.
macOS	Your macOS policy would ideally be configured with Certificate-Based Authentication. If you want to allow a fallback for unmanaged devices, you can choose a fallback authentication. If you are sending the failure notification back to Okta/PING, do not configure a fallback. FIDO2 Authentication is also now available.
Windows 10 enrollment	If you are doing Azure AD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a third-party IdP. Note: This is required if Windows 10 (AAD) enrollments are expected through Okta/ADFS and if Office 365 is included in this policy. Note: For Okta, this will only work when configured with routing rules.
Windows 10	Your Windows 10 policy would ideally be configured with Certificate-Based Authentication. If you want to allow a fallback for unmanaged devices, you can choose a fallback authentication. FIDO2 Authentication is also now available.
Chrome OS	Your Chrome OS Policy would ideally be configured with Certificate Based Authentication. If your Chrome OS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Linux	Your Linux Policy would ideally be configured with Certificate Based Authentication. If your Linux devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Web browser	This can be used as catch all for all Desktop platforms if they all share the same policy setup.

For more details, see Omnissa Access: Best Practices in Policy Management.

Define a sample Okta/Ping/ADFS Medium Security access policy

Your “Okta/Ping/ADFS Medium Security” will be used for the following purposes:

• Applications when configured with another IDP as a broker.
• These policies will not use weak authentication methods (such as Password) and will also not allow for any fallbacks.
• This policy will be used by the Original Okta Device Trust integration.

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO. Do not configure a fallback authentication mechanism.
Android	This authentication should use Mobile SSO. Do not configure a fallback authentication mechanism.
macOS	Your macOS policy should be configured with Certificate-Based Authentication. Do not configure a fallback authentication mechanism.
Windows 10 enrollment	If you are doing Azure AD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a third-party IdP. Note: This is required if Windows 10 (AAD) enrollments are expected through Okta/ADFS and if Office 365 is included in this policy. Note: For Okta, this will only work when configured with routing rules.
Windows 10	Your Windows 10 policy should be configured with Certificate-Based Authentication. Do not configure a fallback authentication mechanism.
Chrome OS	Your Chrome OS Policy policy should be configured with Certificate-Based Authentication. Do not configure a fallback authentication mechanism.
Linux	Your Linux Policy policy should be configured with Certificate-Based Authentication. Do not configure a fallback authentication mechanism.
Web browser	This can be used as catch all for all Desktop platforms if they all share the same policy setup

For more details, see Omnissa Access: Best Practices in Policy Management.

Define a sample Okta/Ping/ADFS High Security access policy

Your “Okta/Ping/ADFS High Security” will be used for the following purposes:

• Applications when configured with another IdP as a broker.
• These policies will include a Device Compliance policy.
• These policies will not use weak authentication methods (such as Password) and will also not allow for any fallbacks.

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO + Device Compliance. Do not configure a fallback authentication mechanism.
Android	This authentication should use Mobile SSO + Device Compliance. Do not configure a fallback authentication mechanism.
macOS	Your macOS policy should be configured with Certificate-Based Authentication + Device Compliance. Do not configure a fallback authentication mechanism. If you want you use FIDO2 on your high security applications we recommend you include Certificate Authentication + Device Compliance in your policy rule.
Windows 10 enrollment	If you are doing Azure AD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a 3rd Party IDP. Note: This is required if Windows 10 (AAD) enrollments are expected through Okta/ADFS and if Office 365 is included in this policy. Note: For Okta, this will only work when configured with routing rules.
Windows 10	Your Windows 10 Policy should be configured with Certificate-Based Authentication+ Device Compliance. Do not configure a fallback authentication mechanism. If you want you use FIDO2 on your high security applications we recommend you include Certificate Authentication + Device Compliance in your policy rule.
Chrome OS	Your Chrome OS policy should be configured with Certificate-Based Authentication. Note: Device Compliance is not available for Chrome OS.
Linux	Your Chrome OS policy should be configured with Certificate-Based Authentication. Note: Device Compliance is not available for Linux

For more details, see Omnissa Access: Best Practices in Policy Management.

Define a sample Horizon/Citrix access policy

Your “Horizon/Citrix” will be used for the following purposes:

• This is for your Virtual Apps

Note: When Horizon/Citrix sync new Applications/Desktops, they will have to be manually assigned this policy. New applications will automatically get the default policy.

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO. If you want to allow a fallback for unmanaged devices, you can choose a fallback authentication.
Android	This authentication should use Mobile SSO. If you want to allow a fallback for unmanaged devices, you can choose a fallback authentication.
macOS	Your macOS policy would ideally be configured with certificate-based authentication. If your macOS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Windows 10	Your Windows 10 policy would ideally be configured with certificate-based authentication. If your Windows 10 devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Chrome OS	Your Chrome OS Policy would ideally be configured with Certificate Based Authentication. If your Chrome OS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Linux	Your Linux Policy would ideally be configured with Certificate Based Authentication. If your Linux devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Web browser	This can be used as catch all for all Desktop platforms if they all share the same policy setup.

For more details, see Omnissa Access: Best Practices in Policy Management.

Tips and Tricks

Why does it say “cloud deployment” when I deployed on-premises?

The Password (cloud deployment) is just the name of this authentication method, which indicates that the outbound mode is being used to connect. When you select this option, you activate the capability for Omnissa Access to prompt for authentication. The clients never communicate directly to the Connector.

Can I use DNS C-names?

No. C-Names do not work. Omnissa Access depends on A records and PTR records for the Service URL. The same is true for the Connector FQDN, as well as the local Service Node FQDN. You cannot fake a new FQDN by using a C-Name. If you want to allow your users to use another FQDN for accessing the Omnissa Access Service, you can use 301 permanent redirect. In that case, for example, a user enters login.company.com, and gets redirected to the correct Service URL.

Which databases are supported?

Only one database is supported: Microsoft SQL Server database when deploying for a regular end-user computing use case or clustering. When doing an SDDC use case built-in vPostgres is supported for a single node implementation.

How can I avoid time-related issues?

To avoid time-related issues, make sure you configure a Network Time Protocol (NTP) server. Omnissa Access must be time-synched with the rest of the infrastructure to function properly. It sends SAML assertions back and forth between the Connector and the Service. Although SAML typically have a Time-To-Live of about 5 minutes, it is not 5 minutes in both directions. Omnissa Access only allows for 30 seconds from future messages. That means that if one of your systems is running 1 minute ahead of time, problems will occur.

By default, the service picks up the time from the underlying ESXi host when you first deploy the Service. If you haven’t time-synched your ESXi host, however, and if you have set up a cluster, it is likely that a time difference will occur between components. To avoid this, make sure to specify an NTP server in the UI when you first deploy the service.

How can I resolve cluster issues using OpenSearch and Omnissa Access?

If your System Diagnostic Dashboard shows errors under Integrated Components, it is very likely because of an issue with your OpenSearch cluster. Most issues with OpenSearch and Omnissa Access arise when creating clusters. For more information, see Troubleshooting OpenSearch Cluster Health.

Why are users prompted for username identification?

When configuring your access policies, users might be prompted to identify themselves before they authenticate.

There are two reasons why this will happen. The most common reason is because you have added a group condition in your Access Policy:

When you add a group condition, Omnissa Access requires the user to enter their username/email first to determine if they qualify for the group condition.  

The second reason for this is when you need to select your domain, but you have hidden the domain chooser. In Omnissa Access preferences, you can hide the domain drop-down and require users to select enter their username first. When you hide the domain chooser, Omnissa Access will ask for your username/email for all authentication methods except Mobile SSO and Certificate. If multiple users share the same username/email, you will be prompted with the domain chooser.

For more details, see Omnissa Access: Best Practices in Policy Management.

How can I learn more about Omnissa Access?

For more information about Omnissa Access, see the Omnissa Access product page.

Summary

  This asset has provided tips, best practices, and FAQs to assist you with architecting Omnissa Access, as well as additional sources of information.

Changelog

The following updates were made to this guide:

About the Author and Contributors

This asset was created by:

•  Peter Bjork, Principal Architect, Omnissa
• Sascha Warno, Staff Architect, Omnissa
• Cindy Carroll, Omnissa alumni

With significant contributions from:

• Steven D’Sa, Omnissa alumni

Feedback

Your feedback is valuable.

To comment on this paper, contact End-User-Computing Technical Marketing at euc_tech_content_feedback@omnissa.com.