Best Practices and FAQs for Architecting VMware Workspace ONE Access
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 VMware Workspace ONE UEM, VMware Horizon, and VMware Workspace ONE Access to achieve this. Workspace ONE 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 Workspace ONE Access so you can implement it successfully.
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 VMware Workspace ONE® Access (formerly VMware Identity Manager) and VMware Workspace ONE® UEM is also helpful.
Frequently Asked Questions
This section provides advice and tips in the form of frequently asked questions, in which you can find answers to your FAQs, as well as links to additional information.
What are the basic components of Workspace ONE 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 Workspace ONE 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 Workspace ONE 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 Workspace ONE 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 Workspace ONE 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 Workspace ONE 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 Workspace ONE Access service is offered in two different methods of deployment: cloud-hosted and on-premises.
- Cloud-Hosted Service. This option is serviced and handled by VMware 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. This means that VMware owns the domain name, so you cannot choose your own FQDN. For example, in a name like vmwareidentity.com, your company name would precede it, such as companyname.vmwareidentity.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 Workspace ONE 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 Workspace ONE Access with Horizon 7 on-premises or in the cloud, Workspace ONE Dynamic Endpoint Management (DEM) on-premises or in the cloud, and so on.
Workspace ONE UEM
Workspace ONE UEM
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 Workspace ONE 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 Workspace ONE 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, since 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 does the Connector do?
Typically, the Connector is used in both on-premises and cloud-hosted implementations to synchronize users into Workspace ONE 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.
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 VMware NSX-T™ Data Center (formerly NSX-T) 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.
Which authentication methods does Workspace ONE 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.
- MobileSSO (provides seamless authentication on mobile devices, Android and iOS)
- Workspace ONE UEM External Access Token
- Device Compliance (with Workspace ONE UEM)
- VMware Verify
- Password (using Workspace ONE UEM)
- Password Local
- SAML inbound (when using third-party Identity Provider)
Handled by the Connector:
- Microsoft Active Directory Kerberos
- Microsoft Active Directory Username and Password
- RSA SecurID
How does the communication flow work?
Let’s say you have decided to implement cloud-hosted Workspace ONE 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 work?
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.
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 Workspace ONE 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.
Workspace ONE 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 do you configure Outbound Mode?
Configuring Outbound Mode is not immediately logical, so it is described here in detail.
When you have deployed Workspace ONE 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, you need to 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.
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 Workspace ONE Access to prompt for authentication. The clients never communicate directly to the Connector.
How do you implement Workspace ONE Access on-premises?
You need to 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. Workspace ONE 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 Workspace ONE 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. Workspace ONE 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 Workspace ONE 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 Workspace ONE 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 Workspace ONE Access. You can deploy Access within your LAN if you do not require external access or you will use VPN for external access.
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 Workspace ONE Access Service Node has full and low latency access to your database server.
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 high 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 please see the Workspace ONE Reference Architecture.
Can I use DNS C-names?
No. C-Names do not work. Workspace ONE 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 Workspace ONE Access Service, you can use 301 permanent redirect. In that case, for example, a user enters login.vmware.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 a 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. Workspace ONE 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. Workspace ONE 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 learn more about Workspace ONE Access?
For more information about Workspace ONE Access, see the Workspace ONE Access Activity Path.
Summary and Additional Resources
This asset has provided tips, best practices, and FAQs to assist you with architecting Workspace ONE Access, as well as additional sources of information.
For more information about Workspace ONE Access, explore the Workspace ONE Access Activity Path. The activity path provides step-by-step guidance to help you increase your understanding of Workspace ONE Access, including articles, videos, and labs.
You can also see the VMware Workspace ONE and VMware Horizon Reference Architecture, which provides a framework and guidance for architecting an integrated digital workspace using VMware Workspace ONE and VMware Horizon.
Additionally, the following resources can be useful:
- KB: SaaS IP address ranges used for network configuration in Workspace ONE Access
- VMware Workspace ONE Access Product Page
- (Blog) New Simplified Disaster Recovery Architecture for Workspace ONE Access (formerly known as VMware Identity Manager)
- Architecting VMware Identity Manager (aka VMware Workspace ONE Access)
About the Authors and Contributors
This asset was created by:
- Peter Bjork, Senior Staff Architect, End User Computing, VMware
- Cindy Carroll, Technical Marketing Manager, End User Computing, VMware
The purpose of this asset is to assist you. Your feedback is valuable. To comment on this asset, contact VMware End-User-Computing Technical Marketing at firstname.lastname@example.org.