While configuring your network, you must take security measures into account whether you are in a SaaS or an on-premises environment.

SaaS Configurations

With a cloud-based implementation, the Workspace ONE Assist software is delivered as a service (SaaS). The integration between your Workspace ONE UEM SaaS tenant and your Workspace ONE Assist SaaS deployment is configured for you.

Figure 1. Workspace ONE Assist SaaS Deployment
,Deployment,CP Server,Portal Server,DB Server,port 443,Core/App Server,T10 API

If you want your Workspace ONE Assist to run in a SaaS configuration, you must whitelist the following fully qualified domain names (FQDNs) and IP addresses.

The FQDNs and IPs are region specific, so add these to your whitelist based on your location. The port is 443.

For more information, please see the following knowledge base article, https://kb.vmware.com/s/article/82567?lang=en_US

SaaS and On-Prem Config: Additional Network Requirements to Enable Firebase Cloud Messaging (FCM)

You can configure the Android Assist agent to receive a Firebase Cloud Message (FCM) directly from the Assist server during the connection process. Together with Workspace ONE Intelligent Hub for notifications, this configuration improves the establishment speed and reliability of connections, thus minimizing request timeouts and improving the overall admin experience.

To receive FCM notifications, the following endpoints must be accessible on the end user devices.

Destination Host Ports Purpose
fcm.googleapis.com, fcm-xmpp.googleapis.com TCP/443, 5228-5230 Firebase Cloud Messaging (for example Find My Device, EMM Console <-> DPC communication, like pushing configs)
Note: Workspace ONE Assist On-Premises customers with closed networks can continue to invoke Workspace ONE Assist agent through Workspace ONE Intelligent Hub/AWCM wich is enabled by default. It also serves as a backup in case of FCM failures.

On-Prem Config: IP Address and Port Translation, Single-Server On-Prem Deployment

The Workspace ONE Assist server is required to have one static IPv4 address. This address must be accessible from the mobile device network and the network from which Workspace ONE UEM users access the Workspace ONE Assist web portal. This IP address is translated to the all-in-one server’s Portal (web) services and Connection Proctor (CP) services.

By default, web services are bound to port 443 and CP services are bound to port 8443, however, your IT team can customize these ports. If Network Address Translation (NAT) is used, one public facing static IP address is required translated to the internal IP address of the Workspace ONE Assist server.

Port Service
443 * Portal Services and T10 API
8443 * Connection Proctor Service

* Customizable port address

On-Prem Config: IP Address and Port Translation, Medium and Multiple-Server On-Prem Deployment

Each Connection Proctor server must have its own static IPv4 address that is accessible from the device network and the user network that is translated to the CP service using port 443. The server hosting Workspace ONE Assist Web/Portal Services must also have its own static IP address that is accessible from the device network and Workspace ONE UEM user network. The portal services are bound to port 443, however, your IT team can customize these ports.

If network address translation (NAT) is used, the public facing IP addresses must be translated to the internal IP addresses of the servers accordingly.

Core and application components and corresponding services can be deployed on a public facing server or in a private zone. CP services and Portal services must be able to communicate with these core and application services over of a range of ports.

Port Service
443* Portal Services and T10 API
443*

Connection Proctor Service on CP Server.

In a multiple server deployment, the CP server can have port 443. Port 8443 is not necessary since the server has 443 available.
6443*

Management website Services on Portal / Core Server

Assist installer generates an internal SSL certificate during the installation process such that the traffic within the services is secured.
8865 Data Tier Proxy (DTP)
8866 Messaging Entity (MSG)
8867 Data Access Proxy (DAP)
8870 Service Coordinator (SVC)
12780 Connection Proctor (CP) from Management Entity (ME)
20879 Management Entity

* Customizable port address

Database services are deployed on the database server. The Workspace ONE Assist system connects to the database server using an IP address, hostname, or instance name. Typically, SQL database allows connections on port 1433.

On-Prem Config: Persistence for Multiple Server On-Prem Deployment

Workspace ONE Assist supports IP and SSL persistence. SSL persistence is required for connection proctor servers as the SSL termination must be made at the server level.

SSL persistence is also required for T10 service communication. An SSL certificate must be present on the T10 server since this communication cannot be offloaded.

On-Prem Config: Firewall Rules, Single-Server On-Prem Deployment

Firewall rules can be summarized based on the number of allocated IP addresses to the Workspace ONE Assist system.

Source Destination Protocol Port Direction Rule
Device and User Networks / Internet CP Server TCP/TLS/SSL 8443 Inbound Accept
Device and User Networks / Internet Portal Server TCP/HTTPS 443 Inbound Accept
Workspace ONE portal server Portal Server (T10 Interface) TCP/HTTPS 443 Inbound Accept
Workspace ONE Assist server MS SQL Database Server TCP 1433 Inbound Accept

On-Prem Config: Firewall Rules, Multiple Server On-Prem Deployment

Source Destination Protocol Port Direction Rule
Device and User Networks / Internet CP Server TCP/TLS/SSL

443

In a multiple server deployment, the CP server can use port 443. Port 8443 is not necessary since the server has 443 available.

 Inbound Accept
Device and User Networks / Internet Portal Server TCP/HTTPS 443 Inbound Accept
Workspace ONE portal server Portal Server (T10 Interface) TCP/HTTPS 443 Inbound Accept
CP Server and Portal Server Core/App Server TCP 6443, 8865, 8866, 8867, 8870, 20879 Inbound Accept
Core/App Server CP Server TCP 12780 Inbound Accept
Core/App Server Database Server TCP 1433 Inbound Accept

On-Prem Config: Fully Qualified Domain Name and Site SSL/TLS Certificate, Single-Server On-Prem Deployment

The Workspace ONE Assist system requires one FQDN assigned to the static IP address which is used for Portal Services and for Connection Proctor services.

The Site SSL/TLS certificate has the following attributes in a single-server deployment:

  • It is used for TLS/SSL bindings for Portal services.
  • It is used in IIS for the Portal Services bound to port 443.
  • It corresponds to the FQDN.
  • It is used for the Connection Proctor Service bound to port 8443.
  • It contains both public and private key pairs.
  • It must be installed on the Workspace ONE Assist server’s personal certificate store before the Workspace ONE Assist software is installed.

Obtain your SSL/TLS certificate from a well-known certificate authority such as Comodo, GoDaddy, and so on. If you prefer a self-signed certificate, then you must establish trust between the Assist Agent and the self-signed certificate.

Note: For Android (Legacy) devices, self-signed certificates are only supported on Android 6.0 and earlier. The root and intermediate certificates/public key pair must be installed on mobile devices you intend to remote into. For Android devices, please see Establish Trust for the Self-Signed SSL Certificate.

On-Prem Config: Fully Qualified Domain Name and Site SSL/TLS Certificate, Multiple Server On-Prem Deployment

One FQDN is assigned to the Portal server and one FQDN is assigned to each CP server deployed in the Assist system. If a single CP server is deployed, you must have 2 FQDNs. If 2 CP servers are deployed, then 3 FQDNs are required, and so on.

You can obtain a SAN or wildcard site SSL/TLS certificate used for TLS/SSL IIS bindings for the Portal Services. The same SAN or wildcard certificate can be used for the CP servers to bind the CP services. If you have a separate SSL/TLS certificate for each server, then each server must have its own certificate installed. The certificates must correspond to the FQDN assigned to the servers. The certificates must contain both private and public key pairs and they are installed on the server’s local machine certificate store.

Obtain your SSL/TLS certificates from a well-known certificate authority such as Comodo, GoDaddy, and so on. If you prefer a self-signed certificate, then you must establish trust between the Assist Agent and the self-signed certificate.

Establish Trust for the Self-Signed SSL Certificate

To ensure security, you must obtain the SSL certificate issued by a trusted Certificate Authority (CA). Still, if you want to use a self-signed SSL certificate, you must establish trust between your Assist agent and the self-signed SSL certificate.

Note: For Android (Legacy) devices, self-signed certificates are only supported on Android 6.0 and earlier. The root and intermediate certificates/public key pair must be installed on mobile devices you intend to remote into.
To establish trust for the self-signed SSL certificate, you must perform the following tasks:
  1. Generate hash key from the RM console.
  2. Update the self-signed certificate key value in the RM console.
  3. Publish the SSL configuration to the devices from the Workspace ONE UEM console.

Generate hash key from the RM console

To allow the support for the Self-Signed SSL Certificate, two key value parameters must be passed to the Assist agent. For this, you must generate the hash key using the self-signed SSL root and intermediate certificate.

  1. Open your browser and log into the MgmtWebPortal using your credentials.
  2. Click ADMIN from the top menu and then select Client Configuration.
  3. From the Client Configuration drop-down menu, select EMM AppConfig Assistant.
  4. For the Base64 ssl certicate public key, click Choose file and browse to the location where the Root.crt file is stored.
    1. Select the Root.crt file and click Open.
    2. Click Generate Hash on the RM console.
  5. Click Choose file again and browse to the location where the Intermediate.crt file is stored.
    1. Select the Intermediate.crt file and click Open.
    2. Click Generate Hash on the RM console.
  6. Click Choose file again and browse to the location where the End User Certificate (com.crt) is stored.
    1. Select the End User Certificate file and click Open.
    2. Click Generate Hash on the RM console.
  7. Copy the generated hash key. This key is used as the input for the application configuration that is pushed from the Workspace ONE UEM console to the device while enrolling the device to the Assist server.

Update the Self-Signed certificate value in the RM console

After you generate the hash key, you must update the key value to True for the self-signed certificate in the RM console. This update enables the trust on the self-signed certificate.
  1. For the Trust self signed certificate, click the Edit icon.
  2. Change the key value from False to True and then click the Update icon.
Publish the SSL configuration from the Workspace ONE UEM console
To ensure the devices have the root and intermediate certificates, you must publish the SSL configuration to the devices from the Workspace ONE UEM console.
  1. Open the browser and log into the Workspace ONE UEM console.
  2. Navigate to Devices > Profiles & Resources > Profiles and select Add.
  3. Select Add Profile and then select Android.
  4. Configure the General settings. Enter the name and the groups to which the profile must be pushed.
  5. Select the Custom Settings payload and then select Configure.
  6. Enter the SSL configuration details in the custom settings field. The hash key that you generated previously from the RM console must be added as a parameter value to the configuration details.

    <characteristic type="com.airwatch.android.androidwork.app:com.airwatch.rm.agent" uuid="c5f7a5a7-7fe5-4053-b736-f0023717e1eb" target="1" ><parm name="device.security.ssl.b64pubkeys" value="{ENTER SSL HASH HERE}" type="string" /><parm name="device.security.ssl.pinselfsignedcert" value="true" type="boolean" /></characteristic>

  7. Select Select & Publish. The configuration details are pushed to all the devices enrolled to the Organization Group (OG).
Note:
  • The same configuration can also be done through the Profiles tab listed under Staging & Provisioning.
  • After the configuration is pushed to the device, check the troubleshooting logs for successful initiation of remote management.

    If not initiated, re-save the agent settings or uninstall and re-install the Assist agent and check for troubleshooting logs.

  • This configuration works only with Intelligent Hub 19.03 or later. The parsing error seen in earlier versions of the Hub has been fixed in version 19.03.
  • The app configuration is currently supported for Android Enterprise enrolled devices.

On-Premises Deployments Across Public and Private Security Zones

Security zone configuration for Workspace ONE Assist depends upon whether your on-prem environment is composed of a single server or multiple servers.

Single-Server Deployments

The database component can be installed on a database server in the private zone while the rest of the components are installed on the all-in-one server in the public zone. You can deploy the all-in-one server either in the public or private zone but the all-in-one server MUST be accessible from the device network and the user network that uses the Workspace ONE Assist system.

Medium and Multiple Server Deployments

You can deploy Workspace ONE Assist servers across multiple security zones, such as DMZ/public and private. You can deploy all servers in a public zone or a private zone, depending on the network/security requirements. You can also deploy servers across any zone, provided the servers hosting Connection Proctor services and Portal Services are accessible from the device network and user network.

Typically, in multiple server deployments, components must be accessed by the device network and the user network. Because of this dependency, servers deployed in the Public zone include servers hosting Connection Proctor components and Portal services components. Servers deployed in private zones can include Application, Core, and Database components.

Based on hardware scaling, if the Core, Application, and Portal services components are deployed on the same server (CAP server), then this server must be deployed in a public zone. Connection Proctor servers are also deployed in the public zone. The database server is deployed in the private zone.