Workspace ONE UEM Architecture

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

Introduction

VMware Workspace ONE UEM (powered by AirWatch) is responsible for device enrollment, a mobile application catalog, policy enforcement regarding device compliance, and integration with key enterprise services, such as email, content, and social media.

Workspace ONE Unified Endpoint Management (UEM) features include:

• Device management platform – Allows full life-cycle management of a wide variety of devices, including phones, tablets, Windows 10, and rugged and special-purpose devices.
• Application deployment capabilities – Provides automatic deployment or self-service application access for employees.
• User and device profile services – Ensures that configuration settings for users and devices:
  • Comply with enterprise security requirements
  • Simplify end-user access to applications
• Productivity tools – Includes an email client with secure email functionality, a content management tool for securely storing and managing content, and a web browser to ensure secure access to corporate information and tools.

Workspace ONE UEM can be implemented using an on-premises or a cloud-based (SaaS) model. Both models offer the same functionality.

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

Cloud-based Architecture

With a cloud-based implementation, the Workspace ONE UEM software is delivered as a service (SaaS). To synchronize Workspace ONE with internal resources such as Active Directory or a Certificate Authority, you use a separate cloud connector, which can be implemented using an AirWatch Cloud Connector. The separate connector can run within the internal network in an outbound-only connection mode, meaning the connector receives no incoming connections from the DMZ.

The simple implementation usually consists of:

• A Workspace ONE UEM tenant
• VMware AirWatch Cloud Connector

Figure 1: Cloud-Based Workspace ONE UEM Logical Architecture

The main components of Workspace ONE UEM are described in the following table.

Table 2: Workspace ONE UEM Components

Table 3: Implementation Strategy for Cloud-Based Workspace ONE UEM

AirWatch Cloud Connector

Even when utilizing cloud solutions, such as Workspace ONE UEM, you might want to use some in-house components and resources, for example, email relay, directory services (LDAP/ AD), Certificate Authority, and PowerShell Integration with Exchange. These resources are usually secured by strict firewall rules in order to avoid any unintended or malicious access. Even though these components are not exposed to public networks, they offer great benefits when integrated with cloud solutions such as Workspace ONE.

The AirWatch Cloud Connector allows seamless integration of on-premises resources with the Workspace ONE UEM deployment, whether it be cloud-based or on-premises. This allows organizations to leverage the benefits of Workspace ONE UEM, running in any configuration, together with those of their existing LDAP, Certificate Authority, email relay, PowerShell Integration with Exchange, and other internal systems.

The AirWatch Cloud Connector (ACC) runs in the internal network, acting as a proxy that securely transmits requests from Workspace ONE UEM to the organization’s enterprise infrastructure components. The ACC always works in an outbound-only mode, which protects it from targeted inbound attacks and allows it to work with existing firewall rules and configurations.

Workspace ONE UEM and the ACC communicate by means of AirWatch Cloud Messaging (AWCM). This communication is secured through certificate-based authentication, with the certificates generated from a trusted Workspace ONE UEM Certificate Authority.

The ACC integrates with the following internal components:

• Email relay (SMTP)
• Directory services (LDAP/AD)
• Exchange 2010 (PowerShell)
• Syslog (event log data)

The ACC also allows the following PKI integration add-ons:

• Microsoft Certificate Services (PKI)
• Simple Certificate Enrollment Protocol (SCEP PKI)
• Third-party certificate services (on-premises only)
  • OpenTrust CMS Mobile
  • Entrust PKI
  • Symantec MPKI

There is no need to go through AirWatch Cloud Connector for cloud certificate services. You use the ACC only when the PKI is on-premises, not in the cloud (SaaS).

Table 4: Deployment Strategy for the AirWatch Cloud Connector

Scalability

You can configure multiple instances of ACC by installing them on additional dedicated servers using the same installer. The traffic is automatically load-balanced by the AWCM component and does not require a separate load balancer.

Multiple ACC instances can receive traffic (that is, use a live-live configuration) as long as the instances are in the same organization group and connect to the same AWCM server for high availability. Traffic is routed by AWCM using an LRU (least recently used) algorithm, which examines all available connections to decide which ACC node to use for routing the next request.

For recommendations on the number of ACC instances required, and for hardware requirements, see On-Premises Hardware Considerations. Note that the documentation shows only the number of connectors required for each sizing scenario to cope with the load demand. It does not include additional servers in those numbers to account for redundancy.

Table 5: Strategy for Scaling the ACC Deployment

AirWatch Cloud Connector Installation

Refer to the latest VMware Workspace ONE UEM documentation for full details on the VMware AirWatch Cloud Connector Installation Process.

On-Premises Architecture

Workspace ONE UEM is composed of separate services that can be installed on a single- or multiple-server architecture to meet security and load requirements. Service endpoints can be spread across different security zones, with those that require external, inbound access located in a DMZ and the administrative console located in a protected, internal network, as shown in the following figure.

Syncing with internal resources such as Active Directory or a Certificate Authority can be achieved directly from the core components (Device Services and Admin Console) or using an AirWatch Cloud Connector. The separate connector can run within the LAN in outbound-only connection mode, meaning the connector receives no incoming connections from the DMZ.

The implementation is separated into the three main components:

• Workspace ONE UEM Admin Console
• Workspace ONE UEM Device Services
• AirWatch Cloud Connector

The AirWatch Cloud Messaging Service can be installed as part of the Workspace ONE UEM Device Services server, and the API Endpoint is installed as part of the Admin Console server. Depending on the scale of the environment, these can also be deployed on separate servers.

In addition to the components already described for this cloud-based architecture, there are additional components required for an on-premises deployment.

Table 6: Additional On-Premises Workspace ONE UEM Components

Figure 2: On-Premises Simple Workspace ONE UEM Architecture

Table 7: Implementation Strategy for an On-Premises Deployment of Workspace ONE UEM

Database

All critical data and configurations for Workspace ONE UEM are stored in the database. This is the data tier of the solution. Workspace ONE UEM databases are based on the Microsoft SQL Server platform. Application servers receive requests from the console and device users and then process the data and results. No persistent data is maintained on the application servers (device and console services), but user and device sessions are maintained for a short time.

In this reference architecture, Microsoft SQL Server 2016 was used and its cluster offering Always On availability groups, which is supported with Workspace ONE UEM. This allows the deployment of multiple instances of each of the Workspace ONE UEM components, pointing to the same database and protected by an availability group. An availability group listener is the connection 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.

Workspace ONE UEM runs on an external SQL database. Prior to running the Workspace ONE UEM database installer, you must have your database administrator prepare an empty external database and schema. Licensed users can use a Microsoft SQL Server 2012, SQL Server 2014, or SQL Server 2016 database server to set up a high-availability database environment.

For guidance on hardware sizing for Microsoft SQL Servers, see On-Premises Hardware Considerations

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

Memcached

Memcached is a distributed data-caching application available for use with Workspace ONE UEM environments. It reduces the workload on the database. Memcached replaces the previous caching solution, AW Cache, and is recommended for deployments of more than 5,000 devices.

Once enabled in the Workspace ONE UEM Console, Memcached begins storing system settings and organization group tree information as they are accessed by Workspace ONE UEM components. When a request for data is sent, Workspace ONE UEM automatically checks for the results stored in memory by Memcached before checking the database, thereby reducing the database workload. If this process fails, results data is retrieved from the database and stored in Memcached for future queries. As new values are added and existing values are changed, the values are written to both Memcached and the database.

Note: All key/value pairs in Memcached expire after 24 hours.

You can deploy multiple Memcached servers, with each caching a portion of the data, to mitigate against a single server failure degrading the service. With two servers, 50 percent of the data resides on server 1 and 50 percent on server 2, with no replication across servers. A hash table tells the services what data is stored on which server.

If server 1 experiences an outage for any reason, only 50 percent of the cache is impacted. The tables are rebuilt on the second server as services failover to the database and look to cache those gathered items.

For guidance on hardware sizing for Memcached servers, see On-Premises Hardware Considerations

Table 9: Implementation Strategy for Memcached Servers

Load Balancing

To remove a single point of failure, you can deploy more than one instance of the different Workspace ONE UEM components behind an external load balancer. This strategy not only provides redundancy but also allows the load and processing to be spread across multiple instances of the component. To ensure that the load balancer itself does not become a point of failure, most load balancers allow for setup of multiple nodes in a high-availability (HA) or active/passive configuration.

The AirWatch Cloud Connector traffic is load-balanced by the AirWatch Cloud Messaging component. It does not require a separate load balancer. Multiple AirWatch Cloud Connectors in the same organization group that connect to the same cloud messaging server for high availability can all expect to receive traffic (an active-active configuration). How traffic is routed is determined by the component and depends on the current load.

For more information on load balancing recommendations and HA support for the different Workspace ONE UEM components, see Workspace ONE UEM On-Premises Load Balancer Considerations and High Availability Support for Workspace ONE UEM Components.

Scalability and Availability

Workspace ONE UEM core components can be deployed in a single, shared server design, but this is really only recommended for proof-of-concept engagements. For production use, to satisfy load demands and to meet most network architecture designs, the core application components are usually installed on two separate, dedicated servers (Admin Console and Device Services).

For a high-availability environment and to meet load demands of large deployments, multiple instances of each one of these components can be deployed on dedicated servers behind a load balancer.

Table 10: Implementation Strategy for the Workspace ONE UEM Device Services

Table 11: Implementation Strategy for Workspace ONE UEM Console Servers

In larger environments, which generally include 50,000 devices or more, the API and AWCM services should also be located on separate, dedicated servers to remove their load from the Device Services and Admin Console servers.

Table 12: Implementation Strategy for AWCM Servers

Table 13: Implementation Strategy for API Servers

Multiple instances of the AirWatch Cloud Connector (ACC) can be deployed in the internal network for a high-availability environment. The load for this service is balanced without the need for an external load balancer.

Table 14: Implementation Strategy for the ACC

Workspace ONE UEM can be scaled horizontally to meet demands regardless of the number of devices. For server numbers, hardware sizing, and recommended architectures for deployments of varying sizes, see Considerations for Workspace ONE UEM on-premises Hardware Sizing. Note that the guide shows only the number of application server components required for each sizing scenario to cope with the load demand. It does not include additional servers in those numbers to account for redundancy.

Due to the amount of data flowing in and out of the Workspace ONE UEM database, proper sizing of the database server is crucial to a successful deployment. For guidance on sizing the database server resources, CPU, RAM, and disk IO requirements, see On-Premises Hardware Considerations

This reference architecture is designed to accommodate up to 50,000 devices, allowing additional growth over time without a redesign. Multiple nodes of each of the components (Device Services, Admin Consoles, API servers, AWCM servers, AirWatch Cloud Connectors) are recommended to meet the demand. To guarantee the resilience of each service within a single site, additional application servers are added. For example, four Device Services nodes are used instead of the three that would be required to meet only the load demand.

Figure 3: On-Premises Single-Site Scaled Workspace ONE UEM Components

This figure shows a scaled environment suitable for up to 50,000 devices. It will also allow additional growth over time without a redesign because it uses dedicated API servers and AWCM servers.

• Workspace ONE UEM Devices Services servers are located in the DMZ, and a load balancer distributes the load.
• Workspace ONE UEM Admin Console Services, Memcached, AWCM servers, and API servers are hosted in the internal network with a load balancer in front of them.
• AirWatch Cloud Connector servers are hosted in the internal network and can use an outbound-only connection without the need for an external load balancer.

For this reference architecture, split DNS was used; that is, the same fully qualified domain name (FQDN) was used both internally and externally for user access to the Workspace ONE UEM Device Services server. Split DNS is not a strict requirement for a Workspace ONE UEM on-premises deployment but it does improve the user experience.

Multi-site Design

Workspace ONE UEM servers are the primary endpoint for management and provisioning of end user devices. These servers should be deployed to be highly available within a site and deployed in a secondary data center for failover and redundancy. A robust back-up policy for application servers and database servers can minimize the steps required for restoring a Workspace ONE UEM environment in another location.

You can configure disaster recovery (DR) for your Workspace ONE UEM solution using whatever procedures and methods meet your DR policies. Workspace ONE UEM has no dependency on your DR configuration, but we strongly recommend that you develop some type of failover procedures for DR scenarios. Workspace ONE UEM components can be deployed to accommodate most of the typical disaster recovery scenarios.

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

• Workspace ONE UEM Device Services
• Workspace ONE UEM Admin Console
• Workspace ONE UEM AWCM server
• Workspace ONE UEM API server
• AirWatch Cloud Connector
• Memcached server
• SQL database server

Table 15: Site Resilience Strategy for Workspace ONE UEM

Workspace ONE UEM Application Servers and AirWatch Cloud Connectors

To provide site resilience, each site requires its own group of Workspace ONE UEM application and connector servers to allow the site to operate independently, without reliance on another site. One site runs as an active deployment, while the other has a passive deployment.

Within each site, sufficient application servers must be installed to provide local redundancy and withstand the load on its own. The Device Services servers are hosted in the DMZ, while the Admin Console server resides in the internal network. Each site has a local load balancer that distributes the load between the local Device Services servers, and a failure of an individual server is handled with no outage to the service or requirement to fail over to the backup site.

A global load balancer is used in front of each site’s load balancer.

At each site, AirWatch Cloud Connector servers are hosted in the internal network and can use an outbound-only connection.

For recommendations on server quantities and hardware sizing of Device Services and Admin Console servers, see On-Premises Hardware Considerations.

Table 16: Disaster Recovery Strategy for Workspace ONE UEM Application Servers

Multi-site Console Servers

When deploying multiple Console servers, certain Workspace ONE UEM services must be active on only one primary Console server to ensure maximum performance. These services must be turned off on non-primary servers after Workspace ONE UEM installation is complete.

Workspace ONE UEM services that must be active on only one server are:

• AirWatch Device Scheduler
• AirWatch GEM Inventory Service
• Directory Sync
• Content Delivery Service

When you upgrade the Workspace ONE UEM Console servers, the Content Delivery Service automatically restarts. You must then manually turn off the applicable services again on all extra servers to maintain best performance.

Multi-site Database

As previously stated, Workspace ONE UEM supports Microsoft SQL Server 2012 (and later) and its cluster offering Always On availability groups. This allows the deployment of multiple instances of Device Services servers and Workspace ONE UEM Console servers that point to the same database. The database is protected by an availability group, with an availability group listener as the single database connection target for all instances.

For this design, an active/passive database instance was configured using SQL Server Always On. This allows the 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. For details of the implementation we used, see Workspace ONE UEM Configuration.

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

Failover to a Second Site

A Workspace ONE UEM multi-site design allows administrators to maintain constant availability of the different Workspace ONE UEM services in case a disaster renders the original active site unavailable. The following diagram shows a sample multi-site architecture.

Figure 4: On-Premises Multi-site Workspace ONE UEM Components

To achieve failover to a secondary site, manual intervention might be required for two main layers of the solution:

• Database – Depending on the configuration of SQL Server Always On, inter-site failover of the database can be automatic. If necessary, steps should be taken to manually control which site has the active SQL node.
• Device Services – The global load balancer controls which site traffic is directed to. During normal operation, the global load balancer directs traffic to the local load balancer in front of the Device Service servers in Site 1. In a failover scenario, the global load balancer should be changed to direct traffic to the equivalent local load balancer in Site 2.
• Console servers – When multiple Console servers are deployed, ensure the Workspace ONE UEM services mentioned in Multi-site Console Servers, earlier, are active only on the primary servers and are turned off on the non-primary servers for Site 2.

Prerequisites

This section details the prerequisites for the Workspace ONE UEM configuration:

• Network Configuration – Verify that the following requirements are met:
  • Static IP address and DNS Forward (A) are used.
  • Inbound firewall port 443 is open so that external users can connect to the Workspace ONE UEM instance or the load balancer.
• Active Directory – Workspace ONE UEM supports Active Directory configurations on Windows 2008 R2, 2012, 2012 R2, and 2016, including:
  • Single AD domain
  • Multidomain, single forest
  • Multi-forest with trust relationships
  • Multi-forest with untrusted relationships (requires external connector configuration)
  • Active Directory Global Catalog optional for Directory Sync

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

Installation and Initial Configuration

Workspace ONE UEM is delivered as separate installer for the database and application servers. The database installer must be run before installing any of the application servers. For more information on installing Workspace ONE UEM see Workspace ONE UEM Installation.

At a high level, the following tasks should be completed:

• Database:
  • Create the Workspace ONE UEM database.
  • Run the Workspace ONE UEM database installer.
• Application Servers (Console, Device Services, API, and AWCM):
  • Run the application installer on each application server.
  • Select the appropriate services for the component you are installing.
• Run the Secure Channel installer on each AWCM server, and restart the AWCM service after installation is complete.
• Install and configure the Memcached servers.
• Install the AirWatch Cloud Connector.
• Configure Active Directory:
  • Create a connection to Active Directory.
  • Select a bind account with permission to read from AD.
  • Choose groups and users to sync.
  • Initiate a directory sync.
• Configure email (SMTP) (if applicable) at the company organizational group level.
• Upload the SSL certificate for the iOS signing-profile certificate at the global organizational group level.
• Set up Apple Push Notification service (APNs) for iOS devices and a notification service for Android.

Integration with Workspace ONE Access

Integrating Workspace ONE UEM and Workspace ONE Access into your Workspace ONE environment provides several benefits. Workspace ONE uses Workspace ONE Access for authentication, SaaS, and VMware Horizon® application access. Workspace ONE uses Workspace ONE UEM for device enrollment and management.

The integration process between the two solutions is detailed in Integrating Workspace ONE UEM With Workspace ONE Access.

Also see the Workspace ONE UEM and Workspace ONE Access Integration section in Platform Integration for more detail.

Resource Types

A Workspace ONE implementation can include the following types of application resources.

Native Mobile Apps

Native mobile apps from the Apple App Store, Google Play, and the Microsoft Windows Store have brought about new ways of easily accessing tools and information to make users more productive. A challenge has been making the available apps easy to find, install, and control. Workspace ONE UEM has long provided a platform for distribution, management, and security for these apps. Apps can be published from the app stores themselves, or internally developed apps can be uploaded to the Workspace ONE UEM service for distribution to end users.

Figure 5: VMware Native Mobile Apps

Unified App Catalog

When Workspace ONE UEM and Workspace ONE Access are integrated so that apps from both platforms can be enabled for end users, the option to use the unified catalog in Workspace ONE Access is enabled. This catalog pulls entitlements from both platforms and displays them appropriately in the Workspace ONE native app on a mobile device. The Workspace ONE client determines which apps to display on which platform. For example, iOS apps appear only on devices running iOS, and Android apps appear only on Android devices.

Figure 6: Unified Catalog in Workspace ONE Access

Conditional Access

With the Workspace ONE conditional access feature, administrators can create access policies that go beyond the evaluation of user identity and valid credentials. Combining Workspace ONE UEM and Workspace ONE Access, administrators can evaluate the target resource being accessed, the source network from which the request originated, and the type and compliance status of the device. With these criteria, access policies can provide a more sophisticated authentication challenge only when needed or deny access when secure conditions are not met.

Using the Workspace ONE UEM Console to Create Access Policies

Configuration of compliance starts in the Workspace ONE UEM Console. Compliance policies are created by determining:

1. A criterion to check, such as a jail-broken or rooted device
2. An action to take, such as an email to an administrator or a device wipe
3. An escalation to further actions if the device is not returned to compliance within a set time
4. An assignment to devices or users

Examples of rules are listed in the following table.

Table 18: Examples of Access Policy Rules

Refer the section Compliance Policy Rules Descriptions for the complete list. Because not all the options apply to all the platforms, also see Compliance Policy Roles by Platform.

Using the Workspace ONE UEM REST API to Extend Device Compliance Parameters

With the Workspace ONE UEM REST API, the definition of a device’s compliance status can be extended beyond what is available within the Workspace ONE UEM Console by leveraging an integration with one or more partners from the extensive list of VMware Mobile Security Alliance (MSA) partners. For more information, see Zero Trust Security for the Digital Workspace.

To use the device posture from Workspace ONE UEM with Workspace ONE Access, you must enable the Device Compliance option when configuring the Workspace ONE UEM–Workspace ONE Access integration. The Compliance Check function must also be enabled.

Figure 7: Enable Compliance Check

After you enable the compliance check through Workspace ONE UEM, you can add a rule that defines what kind of compliance parameters are checked and what kind of authentication methods are used.

Figure 8: Device Compliance Policy

The device’s unique device identifier (UDID) must also be captured in Workspace ONE UEM and used in the compliance configuration. This feature works with mobile SSO for iOS, mobile SSO for Android, and certificate cloud deployment authentication methods.

Note: Before you use the Device Compliance authentication method, you must use a method that obtains the device UDID. Evaluating device compliance before obtaining the UDID does not result in a positive validation of the device’s status.

Multi-factor Authentication

Workspace ONE Access supports chained, two-factor authentication. The primary authentication methods can be username and password or mobile SSO. You can combine these authentication methods with RADIUS, RSA Adaptive Authentication, and VMware Workspace ONE Verify as secondary authentication methods to achieve additional security for access control.

BYOD and Mobile Application Management - MAM

Bring your own device (BYOD) refers to employees using personal devices to access corporate resources that contain potentially sensitive information. Personal devices could include smartphones, personal computers, or tablets.

Mobile Application Management (MAM) is the ability for administrators to secure and enable IT control of enterprise apps on a mobile device, such as by requiring full device management to access an app, or restricting copy-paste functionality within an app.

Workspace ONE supports a variety of device and application management approaches based on the ownership of the device and the level of security required by an organization. Corporate-owned devices, or devices used within a regulated industry, will likely require a greater level of management than employee-owned devices. However, employees will expect more privacy and fewer restrictions on the devices they own.

Each mobile platform has slightly different terminology to describe management methods, but here are the high-level options:

• Full mobile device management (MDM) – Requires the user to enroll the device into management to access any work applications. Enrollment involves downloading a management, or MDM, profile to the device. This method provides the most device control for the administrator, including full policies and restrictions, attestation and compliance, conditional access, and device remediation. Usually this management method is used for corporate-owned devices; however, some organizations require this level of management for BYOD as well.
• OS partitioned – Management options that are made possible through device manufacturers. This includes iOS User Enrollment and Android Enterprise Work Profile. This configuration separates work apps and data from personal apps and data. See the Managing Android Devices Operational Tutorial or the Guide to Apple’s User Enrollment for more details on these mobile platforms. Partitioning the OS is a common management option for both BYOD and corporate-owned devices because it provides a user-friendly method to distinguish between personal and work apps.
• Registered mode – If configured in the Workspace ONE UEM console, users are able to log in to the Workspace ONE Intelligent Hub app and access applications without full, device-level management (MDM profile). This management method provides the most privacy for the user and is a common option for BYOD. For instructions on enabling access to Intelligent Hub without full device management, see Enable Intelligent Hub Without Requiring Full Management.
• Containerized apps – Across any of the above-mentioned device management options, Workspace ONE provides secure apps that can be accessed by the user regardless of whether a device is fully managed or uses registered mode. Containerized apps include Workspace ONE productivity apps (Intelligent Hub, Boxer, Content, and so on) and apps that include the Workspace ONE SDK. Using containerized apps on a device in registered mode is the most common configuration to achieve BYOD MAM.  Review this Mobile Application Management learning path to learn more about the Workspace ONE productivity apps.

Figure 9: Workspace ONE Device Management Options Along the Continuum

Enabling Adaptive Management for iOS

The Workspace ONE UEM administrator can allow users to log in to Workspace ONE Intelligent Hub without requiring full device management. In other words, the user can access the catalog of corporate applications without installing the iOS MDM profile on their device. This option is called registered mode: the user’s device is registered but not fully managed.

However, if an iOS user attempts to access a restricted corporate application in the catalog that requires MDM enrollment, the user is prompted to install the iOS MDM profile. This is referred to as adaptive management.

Adaptive management can be enabled on an application-by-application basis within the Workspace ONE UEM Console. Within an application profile, an administrator can choose to require device-level management prior to allowing use of a specific app, as shown in the following screenshot.

Figure 10: Mobile Application Deployment in the Workspace ONE UEM Console

When adaptive management is required for an app, the app has an indicator in the catalog, so the end user understands that the app has specific requirements.

Adaptive management is only supported on iOS. The Android platform no longer supports this functionality. The new standard for app deployment with Android is through Android Enterprise, as described in the Application Management for Android part of the Integrating Workspace ONE UEM with Android.

Mobile Single Sign-On

One of the hallmark features of the Workspace ONE experience is mobile SSO technology, which provides the ability to sign in to the app once and gain access to all entitled applications, including SaaS apps. This core capability can help address security concerns and password-cracking attempts and vastly simplifies the end-user experience for a mobile user. A number of methods enable this capability on both Workspace ONE Access and Workspace ONE UEM. SAML becomes a bridge to the apps, but each native mobile platform requires different technologies to enable SSO.

Configuration of mobile SSO for iOS and Android devices can be found in the Workspace ONE UEM Integration with Workspace ONE Access guide.

Mobile SSO for iOS

Kerberos-based SSO is the recommended SSO experience on managed iOS devices. Workspace ONE Access offers a built-in Kerberos adapter, which can handle iOS authentication without the need for device communication to your internal Active Directory servers. In addition, Workspace ONE UEM can distribute identity certificates to devices using a built-in Workspace ONE UEM Certificate Authority, eliminating the requirement to maintain an on-premises CA.

Alternatively, enterprises can use an internal key distribution center (KDC) for SSO authentication, but this typically requires the provisioning of an on-demand VPN. Either option can be configured in the Standard Deployment model, but the built-in KDC must be used in the Simplified Deployment model that is referenced in Implementing Mobile Single Sign-in Authentication for Workspace ONE UEM-Managed iOS Devices.

Mobile SSO for Android

Workspace ONE offers universal Android mobile SSO, which allows users to sign in to enterprise apps securely without a password. Android mobile SSO technology requires device enrollment and the use of Workspace ONE Tunnel to authenticate users against SaaS applications.

Refer to Implementing Mobile Single Sign-On Authentication for Managed Android Devices.

Windows 10 and macOS SSO

Certificate-based SSO is the recommended experience for managed Windows and Mac desktops and laptops. An Active Directory Certificate Services or other CA is required to distribute certificates. Workspace ONE UEM can integrate with an on-premises CA through AirWatch Cloud Connector or an on-demand VPN.

For guidance on Workspace ONE UEM integration with a Certificate Authority, see Certificate Management.

Email Integration

Workspace ONE offers a great number of choices when it comes to devices and email clients. Although this flexibility offers many choices of email clients, it also potentially exposes the enterprise to data leakage due to a lack of control after email messages reach the device.

Another challenge is that many organizations are moving to cloud-based email services, such as Microsoft Office 365 and G Suite (formerly Google Apps for Work). These services provide fewer email control options than the on-premises models that an enterprise might be accustomed to.

This section looks at the email connectivity models and the pros and cons of each.

Secure Email Gateway Proxy Model

The Workspace ONE UEM Secure Email Gateway proxy server is a separate server installed in-line with your existing email server to proxy all email traffic going to mobile devices. Based on the settings you define in the Workspace ONE UEM Console, the Workspace ONE UEM Secure Email Gateway proxy server allows or blocks email for every mobile device it manages, and it relays traffic only from approved devices. With some additional configuration, no devices are allowed to communicate directly with the corporate email server.

Figure 11: Workspace ONE UEM Secure Email Gateway Architecture

Workspace ONE UEM Secure Email Gateway runs as a service on Unified Access Gateway. For architecture and sizing considerations, see Component Design: Unified Access Gateway Architecture.

Direct PowerShell Model

In this model, Workspace ONE UEM adopts a PowerShell administrator role and issues commands to the Exchange ActiveSync infrastructure to permit or deny email access based on the policies defined in the Workspace ONE UEM Console. PowerShell deployments do not require a separate email proxy server, and the installation process is simpler. In the case of an on-premises Exchange server, AirWatch Cloud Connector (ACC) can be leveraged to prevent inbound traffic flow.

Figure 12: Microsoft Office 365 Email Architecture

Supported Email Infrastructure and Models

Use the following table to compare these models and the mail infrastructures they support.

Table 19: Supported Email Deployment Models

Microsoft Office 365 requires additional configuration for the Workspace ONE UEM Secure Email Gateway proxy model. VMware recommends the direct model of integration with cloud-based email servers unless encryption of attachments is required.

The following table summarizes the pros and cons of the deployment features of Workspace ONE UEM Secure Email Gateway and PowerShell to help you choose which deployment is most appropriate.

Table 20: Workspace ONE UEM Secure Email Gateway and PowerShell Feature Comparison

Key Design Considerations

VMware recommends using Workspace ONE UEM Secure Email Gateway for all on-premises email infrastructures with deployments of more than 100,000 devices. For smaller deployments or cloud-based email, PowerShell is another option.

For more information on design considerations for mobile email management, see Mobile Email Management.

Table 21: Email Deployment Model for This Reference Architecture

Next Steps

• Configure Microsoft Office 365 email through PowerShell.
• Configure Workspace ONE Boxer as an email client for deployment as part of device enrollment.

Conditional Access Configured for Microsoft Office 365 Basic Authentication

By default, Microsoft Office 365 basic authentication is vulnerable because credentials are entered in the app itself rather than being submitted to an identity provider (IdP) in a browser, as with modern authentication. However, with Workspace ONE, you can easily enhance the security and control over Microsoft Office 365 with an active flow.

You can now control access to Office 365 active flows based on the following access policies in Workspace ONE Access:

• Network range
• Device OS type
• Group membership
• Email protocol
• Client name

Figure 13: Microsoft Office 365 Active Flow Conditional Access Policies

Content Integration

Mobile content management (MCM) can be critical to device deployment, ensuring that content is safely stored in enterprise repositories and available to end users when and where they need it with the appropriate security controls. The MCM features in Workspace ONE UEM provide users with the content they need while also providing the enterprise with the security control it requires.

Content Management Overview

1. Workspace ONE UEM managed content repository – Workspace ONE UEM administrators with the appropriate permissions can upload content to the repository and have complete control over the files that are stored in it.

The synchronization process involves two components:

• VMware Content Gateway – This on-premises node provides secure access to content repositories or internal file shares. You can deploy it as a service on a VMware Unified Access Gateway virtual appliance. This gateway supports both cascade mode (formally known as relay-endpoint) and basic (formally known as endpoint-only) deployment models.
• Corporate file server – This preexisting repository can reside within an organization’s internal network or on a cloud service. Depending on an organization’s structure, the Workspace ONE UEM administrator might not have administrative permissions for the corporate file server.

2. VMware Workspace ONE Content – After this app is deployed to end-user devices, users can access content that conforms to the configured set of parameters.

Figure 14: Mobile Content Management with Workspace ONE UEM

You can integrate Workspace ONE Content with a large number of corporate file services, including Box, Google Drive, network shares, various Microsoft services, and most websites that support Web Distributed Authoring and Versioning (WebDAV). It is beyond the scope of this document to list all of them.

For full design considerations for mobile content management, see the most Mobile Content Management.

Content Gateway

VMware Content Gateway provides a secure and effective method for end users to access internal repositories. Users are granted access only to their approved files and folders based on the access control lists defined in the internal repository through Workspace ONE Content. To prevent security vulnerabilities, Content Gateway servers support only Server Message Block (SMB) v2.0 and SMBv3.0. SMBv2.0 is the default. Content Gateway offers basic and cascade mode (formally known as relay-endpoint) architecture models for deployment.

Content Gateway can be deployed as a service within VMware Unified Access Gateway 3.3.2 and later. For guidance on deployment and configuration of Content Gateway service, see Content Gateway on Unified Access Gateway.

For step-by-step instructions, see Configuring Content Gateway Edge Services on Unified Access Gateway.

Scalability

Unified Access Gateway can be used to provide edge and gateway services for VMware Content Gateway, Secure Email Gateway, and VMware Tunnel functionality. For architecture and sizing guidance, see Unified Access Gateway Architecture.

Data Protection in Workspace ONE Content

Workspace ONE Content provides considerable control over the types of activities that a user can perform with documents that have been synced to a mobile device. Applications must be developed using Workspace ONE SDK features or must be wrapped to use these restrictions. The following table lists the data loss prevention features that can be controlled.

Table 22: Data Loss Prevention Features

Content Key Design Considerations

Because this environment is configured with Microsoft Office 365, SharePoint-based document repositories are configured as part of the Workspace ONE Content implementation. Data loss prevention (DLP) controls are used in the Mobile Productivity service and Mobile Application Workspace profiles to protect corporate information.

Table 22: Implementation Strategy for Providing Content Gateway Services

VMware Tunnel

VMware Tunnel leverages unique certificates deployed from Workspace ONE UEM to authenticate and encrypt traffic from the mobile device to resources on the internal network. It consists of following two components:

1. Proxy – This component secures the traffic between the mobile device and the backend resources through the Workspace ONE Web application. To leverage the proxy component with an internally developed app, you must embed the Workspace ONE SDK in the app.

The proxy component, when deployed, supports SSL offloading.

2. Per-App Tunnel – This component allows certain applications on your device to communicate with your backend resources. This restricts access to unwanted applications, unlike the device-level VPN. The Per-App Tunnel supports TCP, UDP and HTTP(S) traffic and works for both public and internally developed apps. It requires the Workspace ONE Tunnel application to be installed and managed by Workspace ONE UEM.

Note: The Per-App Tunnel does not support SSL offloading.

VMware Tunnel Service Deployment

The VMware Tunnel service can be deployed as a service within VMware Unified Access Gateway 3.3.2 and later as the preferred method, or as a standalone Linux server, both deployments support the Proxy and the Per-App Tunnel modules.

For guidance on deployment and configuration of the VMware Tunnel service, see Deploying VMware Tunnel on Unified Access Gateway. For step-by-step instructions, see Configure VMware Tunnel Settings in the Unified Access Gateway UI.

Tunnel Architecture

The Per-App Tunnel component is recommended because it provides most of the functionality with easier installation and maintenance. It leverages native APIs offered by Apple, Google, and Windows to provide a seamless end-user experience and does not require additional configuration as the Proxy model does.

The VMware Tunnel service can reside in:

• DMZ (single-tier, basic mode)
• DMZ and internal network (multi-tier, cascade mode)

Both configurations support load balancing and high availability.

Figure 15: VMware Tunnel and Content Deployment Modes

For guidance on Deployment modes, see Deploying VMware Tunnel on Unified Access Gateway.

Tunnel Scalability

Unified Access Gateway can be used to provide edge and gateway services for VMware Content Gateway and VMWare Tunnel functionality. For architecture and sizing guidance, see Component Design: Unified Access Gateway Architecture.

Tunnel Installation

For installation prerequisites, see System Requirements for Deploying VMware Tunnel with Unified Access Gateway.

After the installation is complete, configure the VMware Tunnel by following the instructions in Configure VMware Tunnel.

Table 23: Strategy for Providing Tunnel Services

Data Loss Prevention

Applications built using the Workspace ONE SDK or wrapped by the Workspace ONE UEM App Wrapping engine can integrate with the SDK settings in the Workspace ONE UEM Console to apply policies, control security and user behavior, and retrieve data for specific mobile applications without changing the application itself. The application can also take advantage of controls designed to make accidental, or even purposeful, distribution of sensitive information more difficult. DLP settings include the ability to prevent copy and paste, prevent printing, prevent the camera or screenshot features, or require adding a watermark to content when viewed on a device. You can configure these features at a platform level with iOS- or Android-specific profiles applied to all devices, or you can associate a specific application for which additional control is required.

Workspace ONE UEM applications, including Workspace ONE Boxer and Workspace ONE Content, are built to the Workspace ONE SDK, conform to the Workspace ONE platform, and can natively take advantage of these capabilities. Other applications can be wrapped to include such functionality, but typically are not enabled for it out of the box.

Figure 16: Workspace ONE UEM Data Loss Prevention Settings

Another set of policies can restrict actions a user can take with email. For managed email clients such as Workspace ONE Boxer, restrictions can be set to govern copy and paste, prevent attachments from being accessed, or force all hyperlinks in email to use a secure browser, such as Workspace ONE Web.

Figure 17: Workspace ONE Boxer Content Restriction Settings

Summary and Additional Resources

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

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

Additional Resources

For more information about VMware Workspace ONE UEM, you can explore the following resources:

• VMware Workspace ONE UEM product page
• VMware Workspace ONE UEM documentation

• VMware Knowledge Base
• VMware Product Interoperability Matrix
• VMware Professional Services

Changelog

The following updates were made to this guide:

Author and Contributors

This chapter was written by:

• Andreano Lanusse, Staff End-User-Computing (EUC) Architect in End-User-Computing Technical Marketing, VMware.
• Christina Minihan, Senior Technical Marketing Architect in End-User-Computing Technical Marketing, VMware.

Contributors:

• Karim Chelouati, Senior Product Marketing Manager, VMware.
• Graeme Gordon, Senior Staff End-User-Computing (EUC) Architect in End-User-Computing Technical Marketing, VMware.

Feedback

Your feedback is valuable.

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