Windows Modern Management Security Design and Implementation

Introduction

VMware Workspace ONE® enables cloud-native modern management to automate IT operations, harden security, and deliver ready-to-work experiences across every Windows 10 device—whether on or off the enterprise network. This guide will explain how Windows 10 device enrollment is secured and how communication occurs between a Windows 10 device and VMware Workspace ONE® UEM (Unified Endpoint Management).

Audience

This guide is intended for prospective and current IT administrators of Workspace ONE, information system security professionals, and anyone who uses the Workspace ONE platform. Familiarity with security, networking and storage in a virtual environment, Active Directory, identity management, and directory services is assumed. Knowledge of VMware Workspace ONE® UEM, VMware Workspace ONE® Access, and VMware Horizon® is also helpful.

Windows Modern Management Framework Overview

There are several communication channels and clients used to manage Windows 10 devices. Before proceeding with the other sections, it is essential to understand these components. The following sections build off this knowledge to explain how device enrollment and management is secured when using Workspace ONE UEM.

Figure 1: Windows Modern Management Framework showing management client responsibilities

Device Management Client Summary

Real-time communication between Windows 10 devices and Workspace ONE occurs over one of two services:

  • Windows Notification Service (WNS)
  • AirWatch Cloud Messaging (AWCM)

There are two primary management clients installed on the device that communicate with Workspace ONE UEM:

  • OMA-DM (Open Mobile Alliance Device Management)
  • VMware Workspace ONE® Intelligent Hub

Each client serves a specific purpose and relies on several services to establish real-time communication with Workspace ONE UEM. The following table compares each client.

Management Clients

 

OMA-DM

VMware Workspace ONE Intelligent Hub

Description

Native MDM client built into the device

Workspace ONE Intelligent Hub installed on the device

Communication

WNS

AWCM

Used for:

  • Device communication
  • Device enrollment
  • Profile configuration using Microsoft CSPs
  • Software distribution metadata delivery using VMware CSPs. Software is installed using the Software Distribution client which is bundled with the Workspace ONE Intelligent Hub.
  • Profile configuration using WAP-Provisioning (Non-Microsoft CSPs)
  • Local policy enforcement
  • Sensors, Scripts, & Workflows
  • Baselines (Microsoft, CIS Benchmark, Custom, Build your Own Baseline, etc.)
  • Unified App Catalog
  • Hub Services
  • Product provisioning

Table 1: Primary Windows 10 Management Clients

For a more detailed discussion of the services used to manage Windows 10 devices, see Troubleshooting Windows 10: Workspace ONE Operational Tutorial.

Network Endpoints

When discussing the network requirements for modern Windows 10 management, it is important to distinguish between Microsoft services required by the operating system versus Workspace ONE UEM network endpoints.

Reference the Microsoft Windows 10 connection endpoints documentation for a detailed list of endpoints required by the Windows 10 operating system. 

For a detailed list of network endpoints and ports required for Workspace ONE UEM, visit the VMware Ports and Protocols page.

Management Certificates

After successful enrollment, there will be two certificates from Workspace ONE UEM in the device. The Device Enrollment certificate is located in Certificates - (Local Computer) > Personal > Certificates and the Application certificate is located in Certificates - Current User > Personal > Certificates, as shown in the following screenshots. The Device Root Certificate can be generated, if not already done so, in the Workspace ONE UEM console. The Device Root Certificate must be generated before enrolling Windows 10 devices because the Device Enrollment certificate is issued by the Device Root Certificate.

Device Enrollment Certificate

This certificate is used for securing the MDM (OMA-DM) communication channel. MDM (OMA-DM) device syncs and check-ins will fail without the Device Enrollment Certificate.

Subject Name Format - AW::{Token}::{Device Services URL}::{Token}

Issued by AwDeviceRoot

Valid for 20 years

Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2)

Key Usage: Digital Signature (80)

Signature Algorithm is sha512RSA

Signature Hash Algorithm is sha512

Public Key Length: 2048-bit RSA key

Application Certificate

This certificate is used by Workspace ONE Universal Windows Platform (UWP) apps to retrieve device and environment details. You are likely not using any of the Workspace ONE UWP apps as these were all converted to desktop apps. The Application Certificate is delivered as a SCEP payload and is not used during enrollment or device management communications.

Subject Name Format - {Device UUID}:{Enrollment UPN}:{Device Services URL}:{One Time Token}:{Group ID}

Issued by AirWatchCA

Valid for 10 years

Enhanced Key Usage: Certificate Request Agent (1.3.6.1.4.1.311.20.2.1)

Key Usage: Digital Signature, Data Encipherment (90)

Signature Algorithm is sha512RSA

Signature Hash Algorithm is sha512

Public Key Length: 2048-bit RSA key

 

image 83

Figure 2: Location of Workspace ONE certificates on a Windows 10 device

For a detailed discussion of the certificates used by Windows 10 during enrollment, refer to the Microsoft documentation: [MS-MDE2]: Mobile Device Enrollment Protocol Version 2.

Windows Device Enrollment Communication Flows

As discussed in the Device Management Client Summary section, two primary management clients installed on the device communicate with Workspace ONE UEM: Workspace ONE Intelligent Hub for Windows and the built-in device management and enrollment client. The underlying device enrollment leverages the Microsoft Mobile Device Enrollment version 2 [MS-MDE2] protocol to enable the device to be enrolled with Workspace ONE UEM or any Device Management Service (DMS).

Two example sequences are shown in Figure 3 and Figure 5, which cover the base enrollment methods, meaning all other enrollment methods leverage these steps at their core. You can easily see this is true if you compare the final steps of Figure 3 and Figure 5 which both leverages the MS-MDE2 protocol to complete enrollment.

The MS-MDE2 device enrollment process can be broken down into five phases: resolve discovery service, discover enrollment services, request and receive security token to authenticate against enrollment services, get certificate policies [MS-XCEP], and complete enrollment [NS-WSTEP]. Workspace ONE UEM supports various enrollment methods, but core enrollment will leverage these five phases.

Workspace ONE UEM leverages HTTPS for transport protection to secure the device/server interaction. We will discuss how to enhance the communication security when leveraging the MS-MDM protocol once the device is enrolled and has been provisioned an X.509v3 certificate (Device Enrollment Certificate). Additionally, Workspace ONE UEM leverages Cookies (DMLocationGroupId, ASP.NET_SessionId, _RequestVerficationToken) and HTTP Strict Transport Security (HSTS) to protect against man-in-the-middle (MitM) attacks such as cookie hijacking. This forces the use of only HTTPS connections (TLS/SSL).

Sample Sequence of Native MDM Enrollment using Windows Auto-Discovery and Workspace ONE Auto-Discovery

Figure 3: Sample Sequence of Native MDM Enrollment using Windows Auto-Discovery and Workspace ONE Auto-Discovery

Figure 3 depicts a sample sequence for a user enrolling using Native MDM Enrollment (Access Work or School > Enroll only in Device Management). This sample was completed with a Windows 10 Enterprise 20H2 (10.0.19042) device. The Windows and Workspace ONE Auto-Discovery services were used but are entirely optional. Without these auto-discovery services, users would be required to enter in their Device Services hostname and Group ID, e.g., DS###.awmdm.com and Acme123. Workspace ONE UEM version 2105 was used as well. However, none of the previous versions impact the enrollment flows.

The steps covered in Figure 3 are as follows:

  1. The user enters their email address via the native enrollment client.
  2. The enrollment client extracts the domain suffix (e.g., domain could be vmware.com) from the email address, prepends the domain name with a well-known label (e.g., EnterpriseEnrollment.domain), and resolves the address to the Windows Auto-Discovery Service (DS). The administrator configures the network name resolution service (that is, the Domain Name System (DNS)) appropriately. VMware offers a cloud-hosted Windows Auto-Discovery service (WADS) which can be configured within the Workspace ONE UEM console. The administrator is required to configure CNAME and provide the appropriate certificate during configuration. The WADS prevents the user from having to enter the Device Services hostname (e.g., DS###.awmdm.com) in addition to their email address during native device management enrollment. For other enrollment methods, the WADS is not used at all. If WADS is not used then the Discovery Service (DS) would be sent directly to the Workspace ONE UEM Device Services endpoint (e.g., https://DeviceServices/DeviceServices/Discovery.svc).
  3. The enrollment client sends an HTTP GET request to the Discovery Service (DS) to validate the existence of the service endpoint.
  4. The enrollment client sends a Discover (e.g., https://EnterpriseEnrollment.domain/EnrollmentServer/Discovery.svc) message (MS-MDE2 section 3.1.4.1.1.1) to the Discovery Service (DS). The Discovery Service (DS) responds with a DiscoverResponse message (MS-MDE2 section 3.1.4.1.1.2) containing the Uniform Resource Locators (URLs) of service endpoints required for the following steps:
    1. https://DeviceServices/DeviceManagement/Enrollment?GID=GroupID
    2. https://DeviceServices/DeviceServices/Policy.svc
    3. https://DeviceServices/DeviceServices/Enrollment.svc

The Discovery Service (DS) sends the domain information (e.g, https://discovery.awmdm.com/Autodiscovery/awcredentials.aws/v2/domainlookup/domain/domain) to the Workspace ONE Auto-Discovery service, if configured/registered, to attempt to determine the user’s Group ID and enrollment URL for enrollment.

  1. The enrollment client then hits the enrollment URL (e.g., https://DeviceServices/DeviceManagement/Enrollment?GID=GroupID). Depending on the configurations and customizations completed by the administrator in the Workspace ONE UEM console, users will see various prompts such as a welcome message before authenticating.
  2. User provides authentication credentials which are sent to the Device Services endpoint along with the session ID, request verification token, and the device platform ID. Depending on configurations there maybe additional redirects at this step, such as when using SAML authentication. An example of this flow is covered in Figure 5.
  3. Once successfully authenticated, depending on the configurations and customizations completed by the administrator in the Workspace ONE UEM console, users will see various prompts such as having to accept the terms and conditions.
  4. The enrollment client communicates with the Workspace ONE UEM Device Service’s security token service (STS) (MS-MDE2 section 3.2) (e.g., https://DeviceServices/DeviceManagement/Enrollment/create-authenticationPayload?sid=SessionID) to obtain a security token to authenticate.
    <form method="post"
           action="ms-app://windows.immersivecontrolpanel">
            <p>
                 <input type="hidden"
                           name="wresult"
                           value="Security Token - SessionID"/>
            </p>
            <input type="submit"/>
    </form>
  5. The enrollment client sends a GetPolicies message (MS-MDE2 section 3.3.4.1.1.1.1) to the Workspace ONE Devices Services endpoint (e.g., https://DeviceServices/DeviceServices/Policy.svc) [MS-XCEP] using the security token (base64 encoded value for wsse:BinarySecurityToken) received in the previous step. The Device Services endpoint [MS-XCEP] responds with a GetPoliciesResponse message (MS-MDE2 section 3.3.4.1.1.2) containing the certificate policies required for the next step. For more information about these messages, see [MS-XCEP] sections 3.3.4.1.1.1.1 and 3.1.4.1.1.2.
  6. The UDID is created at this time before being sent in the next step. For more information about the UDID, refer to Unique Device Identifier (UDID).
  7. The enrollment client then sends a RequestSecurityToken message (MS-MDE2 section 3.4.4.1.1.1.1) to the Devices Services endpoint (e.g., https://DeviceServices/DeviceServices/Enrollment.svc) [MS-WSTEP] using the security token received previously, as well as basic information about the device including the UDID (DeviceID field). The Devices Services endpoint [MS-WSTEP] responds with a RequestSecurityTokenResponseCollection message (MS-MDE2 section 3.4.4.1.1.2) containing the Device Enrollment and Root Certificates and provisioning information for the device management client [MS-MDM]. For more information about these messages, see [MS-WSTEP] sections 3.4.4.1.1.1.1 and 3.1.4.1.1.2.

    Example of the Base64 decoded value set for wsse:BinarySecurityToken in the RequestSecurityTokenResponseCollection. The Workspace ONE Intelligent Hub for Windows processes this information to install the Device Enrollment and Root certificates as well as setting all of the MDM settings on the device.

<wap-provisioningdoc version="1.1">
	<!-- This contains information about issued and trusted certificates. -->
	<characteristic type="CertificateStore">
		<!-- This contains trust certificates. -->
		<characteristic type="Root">
			<characteristic type="System">
				<!--The thumbprint of the certificate to be added to the trusted root store -->
				<characteristic type="6C7703A31E9CC8A0880991F03487DF4C3465160F">
					<!-- Base64 encoding of the trust root certificate -->
					<parm name="EncodedCertificate" value="EncodedCertificate"/>
				</characteristic>
			</characteristic>
		</characteristic>
		<characteristic type="My">
			<characteristic type="User">
				<!-- Client certificate thumbprint. -->
				<characteristic type="DD9BC482B786BF8FC122A2FCDFBA7542481C076B">
					<!-- Base64 encoding of the client certificate -->
					<parm name="EncodedCertificate" value="EncodedCertificate"/>
					<characteristic type="PrivateKeyContainer">
						<parm name="KeySpec" value="2"/>
						<parm name="ContainerName" value="ConfigMgrEnrollment"/>
						<parm name="ProviderType" value="1"/>
					</characteristic>
				</characteristic>
			</characteristic>
		</characteristic>
	</characteristic>
	<!-- Contains information about the management service and configuration for the management agent -->
	<characteristic type="APPLICATION">
		<parm name="APPID" value="w7"/>
		<!-- Management Service Name. -->
		<parm name="PROVIDER-ID" value="AirWatchMDM"/>
		<parm name="NAME" value="Workspace ONE"/>
		<!-- Link to an application that the management service may provide eg a Windows Store application link. The Enrollment Client may show this link in its UX.-->
		<parm name="SSPHyperlink" value="http://apps.microsoft.com/windows/en-in/app/b244d8c8-b13c-49fa-8432-044d724780f2"/>
		<!-- Management Service URL. -->
		<parm name="ADDR" value="https://DeviceServices/DeviceServices/Dm.svc/token/Token/UDID"/>
		<parm name="ServerList" value="https://DeviceServices/DeviceServices/Dm.svc/token/Token/UDID"/>
		<parm name="ROLE" value="4294967295"/>
		<!-- Discriminator to set whether the client should do Certificate Revocation List checking. -->
		<parm name="CRLCheck" value="0"/>
		<parm name="CONNRETRYFREQ" value="6"/>
		<parm name="INITIALBACKOFFTIME" value="30000"/>
		<parm name="MAXBACKOFFTIME" value="120000"/>
		<parm name="BACKCOMPATRETRYDISABLED"/>
		<parm name="DEFAULTENCODING" value="application/vnd.syncml.dm+xml"/>
		<!-- Search criteria for client to find the client certificate using subject name of the certificate -->
		<parm name="SSLCLIENTCERTSEARCHCRITERIA" value="Subject=CN%3DAW%3A%3AToken%3A%3ADeviceServices%3A%3AToken&amp;Stores=MY%5CUser"/>
		<characteristic type="APPAUTH">
			<parm name="AAUTHLEVEL" value="CLIENT"/>
			<parm name="AAUTHTYPE" value="DIGEST"/>
			<parm name="AAUTHSECRET" value="dummy"/>
			<parm name="AAUTHDATA" value="nonce"/>
		</characteristic>
		<characteristic type="APPAUTH">
			<parm name="AAUTHLEVEL" value="APPSRV"/>
			<parm name="AAUTHTYPE" value="DIGEST"/>
			<parm name="AAUTHNAME" value="dummy"/>
			<parm name="AAUTHSECRET" value="dummy"/>
			<parm name="AAUTHDATA" value="nonce"/>
		</characteristic>
	</characteristic>
	<characteristic type="DMClient">
		<characteristic type="Provider">
			<characteristic type="AirWatchMDM">
				<characteristic type="Poll">
					<parm name="NumberOfFirstRetries" value="5" datatype="integer"/>
					<parm name="IntervalForFirstSetOfRetries" value="3" datatype="integer"/>
					<parm name="NumberOfSecondRetries" value="8" datatype="integer"/>
					<parm name="IntervalForSecondSetOfRetries" value="15" datatype="integer"/>
					<parm name="NumberOfRemainingScheduledRetries" value="0" datatype="integer"/>
					<parm name="IntervalForRemainingScheduledRetries" value="480" datatype="integer"/>
				</characteristic>
				<parm name="EntDeviceName" value="Workspace ONE" datatype="string"/>
			</characteristic>
		</characteristic>
	</characteristic>
</wap-provisioningdoc>

Figure 4: Decoded Device Enrollment Provisioning payload used by Intelligent Hub. Contains Device Root Certificate, Device Enrollment Certificate, as well as MDM provisioning information.

Workspace ONE Intelligent Hub Initiated Enrollment using Workspace ONE Access as Source of Authentication and Workspace ONE Auto-Discovery

Figure 5: Sample Sequence of Workspace ONE Intelligent Hub Initiated Enrollment using Workspace ONE Access as Source of Authentication and Workspace ONE Auto-Discovery

Figure 5 depicts a sample sequence for a user enrolling using the Workspace ONE Intelligent Hub initiated enrollment. This sample was completed with a Windows 10 Enterprise 20H2 (10.0.19042) device. The Workspace ONE Auto-Discovery services was used but is entirely optional. This example also uses Workspace ONE Access for the source of authentication, instead of Workspace ONE UEM. This was chosen to defer from Figure 3 and to add more complexities such as when using SAML authentication. Without the auto-discovery service, users would be required to enter in their Device Services hostname and Group ID, e.g., DS###.awmdm.com and Acme123. Workspace ONE UEM version 2105 was used as well. However, all the previous versions do not change the enrollment flows.

The steps covered in Figure 5 are as follows:

  1. The user downloads and installs the Workspace ONE Intelligent Hub for Windows from https://getwsone.com/.
  2. The user enters their email address into the Intelligent Hub. If the corporate domain has not been registered with the Workspace ONE Auto-Discovery service, then the user will be required to enter the Device Services hostname (e.g., DS###.awmdm.com) and Group ID.
  3. The Intelligent Hub extracts the domain suffix (e.g., domain could be vmware.com) from the email address. The Intelligent Hub then sends the domain information (e.g., https://discovery.awmdm.com/Autodiscovery/awcredentials.aws/v2/domainlookup/domain/domain) to the Workspace ONE Auto-Discovery service, if configured/registered, to attempt to determine the user’s Group ID (e.g., Acme123) and enrollment URL (e.g., https://DeviceServices/DeviceManagement/Enrollment) for enrollment.

    Example Header sent to the Workspace ONE Auto-Discovery endpoint by the Intelligent Hub. Most of the following endpoints will have similar headers, therefore this is the only example that will be provided.
     

    User-Agent: AirwatchWindowsHubAgent/21.5.3.0
    
    aw-auth-signature-version: 1
    
    aw-auth-signature-method: HMAC-SHA256
    
    aw-auth-realm: device
    
    aw-device-uid: UDID (TempUDID if UDID has not been generated)
    
    aw-auth-group-id: com.airwatch.windows.agent
    
    aw-date: 2021-07-26T19:53:01.135Z
    
    aw-agent-client-version: 21.5.3.0
    
    Authorization: UDID:n2OTG9xLQE7JsxTbxCuRkoOEZeWb0yUWoReAxGQZiWY=
    
    Accept-Language: en
    
    Host: discovery.awmdm.com

     

  4. The Intelligent Hub takes the Device Services hostname along with the Group ID to validate the Group ID (e.g., https://DeviceServices/DeviceServices/Enrollment/AirWatchEnroll.aws/validategroupidentifier) and pull the next steps to be displayed in the Intelligent Hub. If this fails, users will be asked to re-enter the Group ID. Upon success a Session ID is returned along with a Settings Payload (base64 decoded example below) and any next steps such as a Welcome Message. Because the Source of Authentication is set to use Workspace ONE Access, that hostname is also sent.
     
    <wap-provisioningdoc id="423C1596-AC3D-403D-B66B-83A5C49322B6" name="WinRt Default Settings" profile-uuid="08f745f5-f44f-4ac7-a59e-aff213f256c3" version="65" allowRemoval="True">
    	<characteristic type="PasscodePoliciesV2" uuid="64d0dc83-e660-4d9c-bb93-12e4a6c549b0">
    		<parm name="PasscodeMode" value="0"/>
    		<parm name="EnableSingleSignOn" value="True"/>
    		<parm name="EnableIntegratedAuthentication" value="False"/>
    		<parm name="AllowedSites" value=""/>
    		<parm name="AuthenticationType" value="0"/>
    	</characteristic>
    	<characteristic type="DataLossPreventionV2" uuid="5ba27ec8-5c1a-4f17-b30d-5a77b4b8e037">
    		<parm name="EnableDataLossPrevention" value="False"/>
    		<parm name="EnableCopyPaste" value="False"/>
    		<parm name="EnablePrinting" value="False"/>
    		<parm name="LimitDocumentstoOpenOnlyinApprovedApps" value="False"/>
    		<parm name="AllowedApplications" value=""/>
    		<parm name="EnableWatermark" value="False"/>
    		<parm name="OverlayText" value=""/>
    		<parm name="EnableCopyPasteInTo" value="False"/>
    		<parm name="EnableThirdPartyKeyboards" value="False"/>
    	</characteristic>
    	<characteristic type="CompromisedPoliciesV2" uuid="3953b221-fe6b-4cb1-a715-4984f2363137">
    		<parm name="CompromisedProtection" value="True"/>
    		<parm name="policyId" value="com.airwatch.compliance.compromisedPolicy"/>
    	</characteristic>
    	<characteristic type="OfflineAccessPoliciesV2" uuid="35959da7-4076-4e92-b188-09d086342889">
    		<parm name="EnableOfflineAccess" value="True"/>
    		<parm name="MaximumPeriodAllowedOffline" value="259200"/>
    	</characteristic>
    	<characteristic type="BrandingSettingsV2" uuid="0469a40d-746c-4201-a989-a2c6f343ff12">
    		<parm name="EnableBranding" value="FALSE"/>
    	</characteristic>
    	<characteristic type="GeofencingSettingsV2" uuid="3ccdb602-7762-48ff-882a-0270e447ff48">
    		<parm name="EnableGeofencing" value="False"/>
    	</characteristic>
    	<characteristic type="AnalyticsSettingsV2" uuid="3368beb6-a8b6-4924-a40f-a3a6e7d44ea0">
    		<parm name="EnableAnalytics" value="True"/>
    	</characteristic>
    	<characteristic type="LoggingSettingsV2" uuid="7250939f-b95e-4e32-9c5c-3e9facea2abe">
    		<parm name="EnableLogging" value="FALSE"/>
    		<parm name="LoggingLevel" value="0"/>
    		<parm name="SendLogsOverWifi" value="FALSE"/>
    	</characteristic>
    	<characteristic type="AppTunnelingPoliciesV2" uuid="9c2b4543-0ba0-4732-a73a-d9497b27e9ac">
    		<parm name="EnableAppTunnel" value="False"/>
    	</characteristic>
    	<characteristic type="NetworkAccessV2" uuid="7a48266a-d591-4396-979a-8f87e133d2a4">
    		<parm name="EnableNetworkAccess" value="False"/>
    		<parm name="AllowCellularConnection" value="2"/>
    		<parm name="AllowWiFiConnection" value="1"/>
    		<parm name="AllowedSSIDs" value=""/>
    	</characteristic>
    	<characteristic type="CustomSettingsV2" uuid="bcc61a51-3ffe-44d3-86a5-ae0527965493">
    		<parm name="CustomSettings" value=""/>
    	</characteristic>
    </wap-provisioningdoc>

    Figure 6: Workspace ONE Intelligent Hub Default Settings received during Enrollment

  5. Because Workspace ONE Access is used as the Source of Authentication, the Intelligent Hub will send a request (e.g., https://AccessURL/catalog-portal/services/api/resources/hub-branding) to obtain the Hub custom branding such as colors and logos.
  6. Depending on the configurations and customizations completed by the administrator in the Workspace ONE UEM console, users will see various prompts such as a welcome message before authenticating.
  7. The user is prompted to enter their username or email address. The Intelligent Hub will validate (e.g., https://DeviceServices/DeviceServices/Enrollment/AirWatchEnroll.aws/validateusername) the username with the Workspace ONE UEM Device Services endpoint. The Device Services endpoint sends back next steps which contain the information such as login hint, Access hostname, and so on.
  8. The Intelligent Hub then starts the OAuth2 authentication request via multiple redirects within Workspace ONE Access (depending on how everything has been configure these endpoints will differ slightly). Finally, a JSON Web Token (JWT) and Relay-State are sent back to the Hub as well as the Login Form for the user to enter their password.
  9. The user enters their password. The Intelligent Hub will send the username, password, and contextId to the https://AccessURL/authcontrol/authenticate endpoint. Various redirects occur again to complete the OAuth2 authentication. An XSRF-Token and HZN attributes are set in the cookie before completing OAuth2 authentication.
  10. The Intelligent Hub uses the OAuth token to retrieve a Client Secret, Access Token, and Refresh Token.
  11. The Intelligent Hub uses the Access Token and the user’s External ID to validate the login credentials before Workspace ONE UEM returns the Agent Token.
  12. After successful authentication, depending on the configurations and customizations completed by the administrator in the Workspace ONE UEM console, users will see various prompts such as having to accept the terms and conditions.
  13. The Intelligent Hub requests an MDM Install URL from the Workspace ONE Device Services endpoint. The Install URL (e.g., InstallUrl=https://DeviceServices/DeviceManagement/InitOTA.ashx?sid=SessionID) is returned within the response JSON and will be used at a later step by the Intelligent Hub after the MS-MDE2 enrollment completes successfully.
  14. The enrollment client (native OMA-DM client) sends an HTTP GET request to the Discovery Service (DS) to validate the existence of the service endpoint.
  15. The enrollment client (native OMA-DM client) sends a Discover (e.g., https://EnterpriseEnrollment.domain/EnrollmentServer/Discovery.svc) message (MS-MDE2 section 3.1.4.1.1.1) to the Discovery Service (DS). The Discovery Service (DS) responds with a DiscoverResponse message (MS-MDE2 section 3.1.4.1.1.2) containing the Uniform Resource Locators (URLs) of service endpoints required for the following steps:
    1. https://DeviceServices/DeviceManagement/Enrollment
    2. https://DeviceServices/DeviceServices/Policy.svc
    3. https://DeviceServices/DeviceServices/Enrollment.svcNote that in the Discover request a default value of staging@aw.com is sent as the Email Address, therefore the Workspace ONE Auto-Discovery service is not used in this flow. The Workspace ONE Auto-Discovery service was used in a previous step already.
  16. The enrollment client (native OMA-DM client) sends a GetPolicies message (MS-MDE2 section 3.3.4.1.1.1.1) to the Workspace ONE Devices Services endpoint (e.g., https://DeviceServices/DeviceServices/Policy.svc) [MS-XCEP] using the security token (base64 encoded value of the Session ID) received in the previous steps. The Device Services endpoint [MS-XCEP] responds with a GetPoliciesResponse message (MS-MDE2 section 3.3.4.1.1.2) containing the certificate policies required for the next step. For more information about these messages, see [MS-XCEP] sections 3.3.4.1.1.1.1 and 3.1.4.1.1.2.
  17. The UDID is created at this time before being sent in the next step. For more information about the UDID, refer to Unique Device Identifier (UDID).
  18. The enrollment client (native OMA-DM client) then sends a RequestSecurityToken message (MS-MDE2 section 3.4.4.1.1.1.1) to the Devices Services endpoint (e.g., https://DeviceServices/DeviceServices/Enrollment.svc) [MS-WSTEP] using the security token received previously, as well as basic information about the device including the UDID (DeviceID field). The Devices Services endpoint [MS-WSTEP] responds with a RequestSecurityTokenResponseCollection message (MS-MDE2 section 3.4.4.1.1.2) containing the Device Enrollment and Root Certificates and provisioning information for the device management client [MS-MDM]. For more information about these messages, see [MS-WSTEP] sections 3.4.4.1.1.1.1 and 3.1.4.1.1.2. For a sample, refer to Figure X: Decoded Device Enrollment Provisioning payload.
  19. The native enrollment client completes enrollment, however, the Intelligent Hub needs to complete enrollment as well. The Intelligent Hub invokes the Install URL (e.g., InstallUrl=https://DeviceServices/DeviceManagement/InitOTA.ashx?sid=SessionID) from the previous step and retrieves the Enroll URL (e.g., https://DeviceServices/DeviceServices/Enrollment/DeviceMdmConfiguration.aspx?sid=SessionID) as well as a Token (e.g., SessionID).
  20. The Workspace ONE Intelligent Hub then hits the Enroll URL posting the following XML.
    <plist version="1.0">
    	<dict>
    		<key>OSVERSION</key>
    		<string>10.0.19042</string>
    		<key>VERSION</key>
    		<string>7.0.0</string>
    		<key>PLATFORM</key>
    		<string>12</string>
    		<key>UDID</key>
    		<string>UDID</string>
    		<key>PRODUCT</key>
    		<string>10.0</string>
    		<key>ACCESSRIGHTS</key>
    		<string>4096</string>
    		<key>CHALLENGE</key>
    		<string>SessionID</string>
    	</dict>
    </plist>
  21. The Intelligent Hub will receive Intelligent Hub settings via a wap-provisioning payload. Now that the Intelligent Hub is fully set up and enrolled, the Workspace ONE resources such as apps and profiles will be provisioned.
    <wap-provisioningdoc id="3C2E85F3-8CEE-4D0B-B907-A344DDF16CD1" name="WinRT8AgentSettings" profile-uuid="99120468-c5d5-4034-9457-c63821dc53e0" version="65" allowRemoval="True">
    	<characteristic type="com.airwatch.winrt.agent.settings" uuid="f2185c28-a929-4d6d-969c-99d2b1d4593f">
    		<parm name="Win32DataSampleInterval" value="360"/>
    		<parm name="AWCMClient.ACMServer" value="AWCMHostname"/>
    		<parm name="AWCMClient.ACMPort" value="2001"/>
    		<parm name="EnableTunnelServer" value="0"/>
    		<parm name="TunnelServerExternalUrl" value="localhost"/>
    		<parm name="TunnelServerExternalPort" value="7779"/>
    		<parm name="TunnelServerInternalUrl" value="localhost"/>
    		<parm name="TunnelServerInternalPort" value="7778"/>
    		<parm name="WebTunnelServerUrl" value="localhost"/>
    		<parm name="WebTunnelServerPort" value="443"/>
    		<parm name="CollectUnmanagedAppListSample" value="True"/>
    		<parm name="HeartbeatInterval" value="0"/>
    		<parm name="DataSampleInterval" value="0"/>
    		<parm name="ProfileRefreshInterval" value="0"/>
    		<parm name="AdministrativePasscode" value="abc"/>
    		<parm name="GPSSampleInterval" value="0"/>
    		<parm name="EnableGPS" value="False"/>
    		<parm name="EnablePushNotificationServices" value="False"/>
    		<parm name="ThirdPartyRemoteManagementEnvironmentName" value="environment:E3FD1FFD-0030-4CF9-97DD-760CD35168CC;tenant:5738737C-2ED8-4D26-A1FE-83DDB8A125CF"/>
    		<parm name="ThirdPartyRemoteManagementHostName" value="AssistURL"/>
    		<parm name="EnabledFeatureFlags" value="FeatureFlags"/>
    		<parm name="IsCustomOnboardingExperienceEnabled" value="True"/>
    		<parm name="CustomOnboardingUserName" value="Hello, First Name"/>
    		<parm name="CustomOnboardingMessage" value="IT is installing all the tools you need to get started. We will let you know as soon as it's ready for use."/>
    		<parm name="CustomOnboardingWelcomeText" value="Welcome to ACME Corp"/>
    		<parm name="DigitalExperienceTelemetryEnabled" value="True"/>
    		<parm name="DeviceOwnershipId" value="1"/>
    		<parm name="DpaApiUrl" value="{DpaApiUrl}"/>
    		<parm name="DpaEventProxyV2Url" value="{DpaEventProxyV2Url}"/>
    		<parm name="ShowPrivacyScreen" value="True"/>
    		<parm name="CollectAnalytics" value="True"/>
    		<parm name="PrivacyLink" value="https://www.vmware.com/help/privacy.html"/>
    		<parm name="EnableOfflineDomainJoin" value="{EnableOfflineDomainJoin}"/>
    		<parm name="ComplianceConditionalAccessConfigurationUrl" value="https://DeviceServices/DevicesGateway/devices/7bd4edb7-e65a-4cc1-a622-7911b60a4c36/conditionalaccess/configurations"/>
    		<parm name="ComplianceConditionalAccessReportingUrl" value="https://DeviceServices/DevicesGateway/devices/7bd4edb7-e65a-4cc1-a622-7911b60a4c36/conditionalaccess/deviceinformation"/>
    		<parm name="DeviceUuid" value="7bd4edb7-e65a-4cc1-a622-7911b60a4c36"/>
    		<parm name="DiskEncryptionSample" value="{WindowsSampleSchedule.DiskEncryptionSample}"/>
    		<parm name="BiosSample" value="{WindowsSampleSchedule.BiosSample}"/>
    		<parm name="CustomAttributeSample" value="{WindowsSampleSchedule.CustomAttributeSample}"/>
    		<parm name="OEMUpdateSample" value="{WindowsSampleSchedule.OEMUpdateSample}"/>
    		<parm name="UnmanagedAppListSample" value="720"/>
    		<parm name="AuthenticationToken" value="35c75e35-2fde-496b-989c-8b60e561dba0"/>
    		<parm name="UDID" value="UDID"/>
    	</characteristic>
    </wap-provisioningdoc>

    Figure 7: Workspace ONE Intelligent Hub Default Settings received during Enrollment

Windows Device Management Communication Flows

As mentioned in Device Management Client Summary, real-time communication between Windows devices and Workspace ONE occurs over one of two services:

  • Windows Notification Service (WNS) which is used by the native OMA-DM client.
  • AirWatch Cloud Messaging (AWCM) which is used by the Workspace ONE Intelligent Hub.

Managed devices periodically poll these endpoints and receive push messages from these endpoints to retrieve updates in real-time. Workspace ONE admins can also query or sync the device to have them check-in with the Workspace ONE Device Services endpoint. Lastly, users can also manually invoke device check-ins either natively via the OMA-DM client or from the Intelligent Hub. All of these methods will vary in the connection steps, but all share the same check-in logic. Figure 8 depicts a sample sequence of a user-initiated sync using the Workspace ONE Intelligent Hub.

Intelligent Hub user initiated sync

Figure 8: Sample Sequence of User-Initiated Sync on the Workspace ONE Intelligent Hub

  1. Device check-in is initiated.
  2. The Intelligent Hub checks to see if any configuration changes occurred with Workspace ONE Access and Hub Services.
  3. The native OMA-DM client (omadmclient.exe) initiates an OMA-DM sync by sending basic details such as login status, UDID, manufacture, model, DM version, and language. A confirmation is sent back confirming the endpoint received the check in. If any OMA-DM resources or commands were queued, they would be processed at this time.
  4. The Intelligent Hub invokes its processor (awprocesscommands.exe) to check for any pending commands to process. A status message is returned. If any Intelligent Hub resources or commands were queued, they would be processed at this time.
  5. Lastly, the Intelligent Hub, checks the sampling endpoint. The Hub uses this endpoint to send the Workspace ONE Devices Services endpoint new samples from the device such as installed apps on the device. The request and response body for the sampling endpoint (interrogator) is a byte stream, therefore it is not easily readable as plain-text. However, this data is not encrypted.

There are many other endpoints, but these are the basic commands/endpoints which kick off many of the other resource unique endpoints. The requests by the Intelligent Hub all contain the following header which uses the unique HMAC as a signature method as well as an authorization that contains the unique UDID of the device.

User-Agent: AirwatchWindowsHubAgent/21.5.2.0
aw-auth-signature-version: 1
aw-auth-signature-method: HMAC-SHA256
aw-auth-realm: device
aw-device-uid: UDID
aw-auth-group-id: com.airwatch.windowsprotectionagent
aw-date: 2021-07-22T20:47:34.544Z
aw-agent-client-version: 21.5.2.0
Authorization: UUID:j0Xt+EKm8e2pKDNdbiuJCVzxWFfh7OfT7iFxPrhY9ok=
Accept-Language: en
Content-Type: text/plain; charset=utf-8
Host: ws1beta.airwlab.com
Content-Length: 152
Expect: 100-continue

Figure 9: Sample Header for Workspace ONE Intelligent Hub requests

Unique Device Identifier (UDID)

Although many hardware identifiers are collected from the device, the unique device identifier (UDID) is the device’s primary key in Workspace ONE UEM. The UDID is generated locally on the device by the Windows operating system. During Windows 10 device management enrollment, the device sends this GUID value of the UDID to Workspace ONE UEM. The DmGetClientHardwareUID and DmSetDeviceClientID functions in the dmcmnutils.dll are responsible for generating the UDID and set this value in the registry: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\MDMDeviceID\DeviceClientIdAfter the value is set, the device sends this value to the Workspace ONE UEM management server during enrollment (MS-MDE2 3.4.4.1.1.1.1). Refer to the enrollment web service request for federated authentication sample from Microsoft’s documentation or the snippet in Figure 10. The DeviceID attribute is what Workspace ONE UEM receives during enrollment and maps this value to UDID.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
            xmlns:a="http://www.w3.org/2005/08/addressing"
            xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
            xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
            xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
            xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
	<s:Header>
		<a:Action s:mustUnderstand="1">http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RST/wstep</a:Action>
		<a:MessageID>urn:uuid:0d5a1441-5891-453b-becf-a2e5f6ea3749</a:MessageID>
		<a:ReplyTo>
			<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
		</a:ReplyTo>
		<a:To s:mustUnderstand="1">https://DeviceServices/DeviceServices/Enrollment.aws</a:To>
		<wsse:Security s:mustUnderstand="1">
			<wsse:BinarySecurityToken ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken"
			                          EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">NDJhNjIwZDUtNWI3ZS00ZWFkLTk1YWMtZWJhNmUxOTliODU1</wsse:BinarySecurityToken>
		</wsse:Security>
	</s:Header>
	<s:Body>
		<wst:RequestSecurityToken>
			<wst:TokenType>http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken</wst:TokenType>
			<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
			<wsse:BinarySecurityToken ValueType="http://schemas.microsoft.com/windows/pki/2009/01/enrollment#PKCS10"
			                          EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">MIICzjCCAboCAQAwSzFJMEcGA1UEAxNAQTg1M0Q1OTUtNTJBOS00RkRELUJGNTEtNUI4RUMwIUI4NzU0RjAxMjg1MjIyNEE5OEZBNkQzNkIwQTI3MUE5ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKonnkfDFGa42oK1rlnel6iWMCR1jM2B2RLE8XpZdQAXMMJvSKZR9QTqzoybIsCB9U4E+frM9Zo8qLpqZdRJkMQB0STfYPUPPou2At2P6V+D6ZLewcLYP8quvgMqEnP1yuA+6i+SENHvUgX1qm6fLTJbjsyDF3pxl9YXDpO1WbSnMsYJioFU40dCn0vXYdkpOhaSCENrlfuQ2L3xlH8xPiXPFOuom8wHc9K2n3M+XOh0Ky6cmAHnaYcqErEH70FghwV12WEQVJYRrpELNdDupymM/ISY9J4UHyI9hIQ7TCffDzuKYrYOrDJB1w68ykLNTFm68zg+qiksEwdEo0yWlQECAwEAAaBCMEAGCSqGSIb3DQEJDjEzMDEwLwYKKwYBBAGCN0IBAAQhQjg3NTRGMDEyODUyMjI0QTk4RkE2RDM2QjBBMjcxQTkAMAkGBSsOAwIdBQADggEBAJZZy6f8sorxOhS9X3SAkp3DzCINsdVFuc3+l+pE/9r5P31Pk9qjanyUOjuldIny1R60/lAX/1EAZ47fH0PI98a6PZlg04PaT3pc04m7W21CNwKKo1KvYN70vla9ObGPmn8PZTR29XHJSGdgqHgXAEPA+nWaBuJxM/shAeNjhIdBdiCSSZ8Bfm7If3btkyI8WJNi+9cjzoiOntEquLz6xNEXbJClouV6uOrT6HFmdZnqVt8N//eh1yhonrmXgFszFxsoC/lebxTfByaYJZ7E5Y9VUCWYdz8h0TyNa81mza2UjVUamSeSlQmNURl8/bu+uAsvzTQzbNF22eD12elEkoU=</wsse:BinarySecurityToken>
			<ac:AdditionalContext xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization">
				<ac:ContextItem Name="UXInitiated">
					<ac:Value>false</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="HWDevID">
					<ac:Value>96F191170A3B1F454017AD733B74537CC3E266FB40B0DE1D43A729949665F0D0</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="Locale">
					<ac:Value>en-US</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="TargetedUserLoggedIn">
					<ac:Value>true</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="OSEdition">
					<ac:Value>4</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="DeviceName">
					<ac:Value>DESKTOP-9SSBNEA</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="MAC">
					<ac:Value>00-0C-29-3F-BD-DE</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="MAC">
					<ac:Value>BC-83-85-E4-9E-60</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="DeviceID">
					<ac:Value>B8754F012852224A98FA6D36B0A271A9</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="EnrollmentType">
					<ac:Value>Full</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="DeviceType">
					<ac:Value>CIMClient_Windows</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="OSVersion">
					<ac:Value>10.0.17763.0</ac:Value>
				</ac:ContextItem>
				<ac:ContextItem Name="ApplicationVersion">
					<ac:Value>10.0.17763.0</ac:Value>
				</ac:ContextItem>
			</ac:AdditionalContext>
		</wst:RequestSecurityToken>
	</s:Body>
</s:Envelope>

Figure 10: Sample Enrollment Web Service Request for Federated Authentication (MS-MDE2 3.4.4.1.1.1.1)

The UDID can be modified on the device if the user has administrative permissions to modify registry entries. However, modifying the UDID after enrollment causes issues and will not successfully spoof or impersonate a device. The Windows 10 system generates this UDID during device management enrollment with the management platform. Refer to Figure 3 and Figure 5 to see when the UDID is generated during these two types of enrollments. This process happens with Windows 10 device management and is irrespective of the management solution. Again, you can refer to the enrollment web service request for federated authentication sample for more information on the MDM enrollment process.

Locally on the device, this value corresponds to the following registry location: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\MDMDeviceID. For example, the value for DeviceClientId, like B8754F012852224A98FA6D36B0A271A9, is generated in real-time during the device’s first enrollment attempt. After the DeviceClientId is created, this value does not change unless it’s manually deleted or the device is wiped/factory reset.

The UDID lives throughout the registry, task schedules, certificate subject names, and so on. Therefore, modifying this value will not successfully spoof/impersonate the device and breaks communication with the MDM management server.

Optionally, to further protect the MDM (OMA-DM) communication channel against spoofing, the Workspace ONE UEM admin can enable the MDM Channel Security setting in the Workspace ONE UEM console. The MDM Channel Security setting is found under All Settings > Devices & Users > Windows > Windows Desktop > Intelligent Hub Settings > MDM Channel Security. You can select from None, Signed, Encrypted, or Signed and Encrypted. For more information, see: https://docs.microsoft.com/en-us/windows/client-management/mdm/dmclient-csp.

Securing Data at Rest

Leveraging BitLocker Encryption

Consumer Simple Encryption

When it comes to BitLocker encryption for Windows 10 devices, the security by design approach provides the best user experience. Security by design implements device encryption in a way that feels like a non-disruptive, natural part of the device experience.

Enterprise Secure Devices

Create a BitLocker encryption profile to keep Windows 10 device data enterprise secure. After the profile is configured, Workspace ONE Intelligent Hub automatically enforces encryption settings as part of the device’s general security posture. Use the Workspace ONE UEM compliance engine to ensure devices remain compliant.

For more information, see Microsoft Docs: BitLocker Overview.

Solving Current Device-Encryption Challenges

Two security principles that are top of mind when dealing with device encryption are least privilege and separation of duties.

Workspace ONE UEM leverages role-based access controls (RBAC) for admins, allowing you to grant access to view recovery keys only to the admins who require access.

In addition to RBAC, Workspace ONE UEM logs each action of viewing a recovery key by each admin to the console event logs, which can also be sent to your preferred Syslog provider. This allows for InfoSec to audit admin access to recovery keys to prevent rogue admins from capturing all recovery keys, for example.

Workspace ONE UEM BitLocker encryption also helps in the following ways:

Current Device Encryption Challenges

Workspace ONE UEM BitLocker Encryption

Additional license costs with third-party tools

Eliminate third-party license cost

Another third-party agent for encryption

Single agent for all advanced management capabilities

Inability to enforce encryption locally on the device

Local enforcement for off-network & off-domain devices

No separation of duties for admins

Granular, role-based access controls

Complex management via GPOs/scripts

Simple profile with comprehensive controls

Recovery key management

Auto escrowing of recovery keys

High help desk costs for end-user recovery

Self-service portal key retrieval

It is recommended to enable BitLocker encryption to further enhance data at rest on the managed device. For more details on deployment and the capabilities via Workspace ONE UEM, refer to Enabling BitLocker Encryption to Remote Windows 10 Devices.

Workspace ONE Intelligent Hub Database Encryption

The Workspace ONE Intelligent Hub stores data locally on the device in a SQLite database located in the install directory in the Data folder (e.g., C:\Program Files (x86)\Airwatch\AgentUI\Data). There are two databases awWindowsAgentProviderDb_Sqlite.sqlite and HubClientDb.sqlite. These SQLite databases leverage a 256-bit AES encryption in CBC mode.

Additional Security Considerations

This section provides high-level guidance on other features built-in to the Windows operating system as well as provided by Workspace ONE to further enhance the security posture of the managed device. These are solely recommendations at what to further explore and do not provide any configuration steps. Every use-case is different, therefore ensure to further research and confirm with your Workspace ONE representative for more details.

Enabling Windows MDM Secure Channel for OMA-DM Communications

Workspace ONE UEM does not use Secure Channel for Windows 10, however, something similar can be done using MDM Channel Security options in the Workspace ONE UEM console.

For additional security you can choose to enable the MDM Channel Security settings in the Workspace ONE UEM console under All Settings > Devices & Users > Windows > Windows Desktop > Intelligent Hub Settings > MDM Channel Security. You can select from None, Signed, Encrypted or Signed and Encrypted. Enabling this setting will force the communication between the Workspace ONE Device Services endpoint and OMA-DM client on the device to either be signed, encrypted, or signed and encrypted. Enabling this feature will mitigates an attacker from snooping and intercepting the SyncML (OMA-DM payloads) and successfully performing man-in-the-middle (MitM) attacks. For more information, see DMClient CSP.

This will set the following registry during enrolment (this setting will only work on newly enrolled devices): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\<Enrollment_GUID>\Protected\ConnInfo, EnhancedAppLayerSecurityCert0. This will have the Thumbprint for the device root certificate for its value. SecurityMode will be set to 0, 1, 2, or 3 which corresponds to none, signed, encrypted, or signed and encrypted. You will only see these values in registry if the Workspace ONE UEM console is set to anything other than none.

Assessing Device Posture

Workspace ONE UEM assesses device posture by evaluating, locally enforcing, and remediating devices using the compliance engine, a Workspace ONE UEM tool that ensures that all devices abide by specified policies. A policy can include basic security settings or more critical security configurations.

The compliance engine detects non-compliant devices and sends end users a warning. If the end user addresses the issue after the warning, no further action is taken. If the end user fails to correct the issue in the specified time-frame, it escalates, and disciplinary actions occur.

Use the Workspace ONE UEM Console to specify the escalation steps, disciplinary actions, grace periods, and messages. For example, the following figure demonstrates a tiered approach to compliance. With each security action, an end user’s non-response escalates the risk level.

Device Health Attestation

Device Health Attestation scans devices during startup for failures in device integrity. Use Device Health Attestation to detect compromised Windows devices managed by Workspace ONE UEM.

In both BYOD and Corporate-Owned device deployments, it is important to know that devices are healthy when accessing corporate resources. The Windows Health Attestation Service accesses device boot information from the cloud through secure communications. This information is measured and checked against related data points to ensure that the device booted up as intended and is not victim to security vulnerabilities or threat. Measurements include Secure Boot, Code Integrity, BitLocker, and Boot Manager.

Workspace ONE UEM enables you to configure the Device Health Attestation service to ensure device compliance. If any of the enabled checks fail, the Workspace ONE UEM compliance policy engine applies security measures based on the configured compliance policy. This functionality allows you to keep your enterprise data secure from compromised devices. Because Workspace ONE UEM pulls the necessary information from the device hardware and not the OS, compromised devices are detected even when the OS kernel is compromised.

For detailed information on how Device Health Attestation works, refer to control the health of Windows 10-based devices.

Preventing Data Loss

Windows Modern Management with Workspace ONE UEM maximizes native Windows Information Protection capabilities to help you minimize the risk of data loss. Use Windows Information Protection to define:

  • Privileged applications
  • Application access
  • Enterprise boundaries
  • Protection levels

Windows Information Protection encrypts all corporate data at the file level and decrypts only when accessed by a privileged application. Although Windows Information Protection can stop accidental data leaks from honest employees, it is not intended to stop malicious insiders from removing enterprise data. For more details about the benefits Windows Information Protection provides, see Microsoft’s article on why you should use WIP.

Note: Windows Information Protection operates on a device level. If data is transferred to a file share or cloud repository, Windows Information Protection cannot guarantee data protection. Instead, shared data requires integration with a rights management service (RMS).

Ensuring Policy Compliance and Enforcement

Workspace ONE UEM allows admins push configurations and group policies to managed device. Whether you are using MDM profiles or Workspace ONE Baselines, the configured policies are enforced locally. MDM profiles are enforced by the OMA-DM client, while Baselines are enforced by the Intelligent Hub.

Workspace ONE Baselines allow you to keep all your devices secure with industry-recommended settings and configurations. It uses a cloud-based micro service that handles the policy catalog of settings to apply on devices. Baselines are based on GPOs and function in similar ways. For more information regarding Baselines, refer to Workspace ONE Baselines Overview.

Workspace ONE allows for an administrator to create baselines based on industry-certified templates such as the CIS Microsoft Windows Desktop Benchmark and the Microsoft Windows 10 Security Baseline. You can add additional policies to a baseline that you create from an easy-to-use catalog of thousands of policies based on the Microsoft ADMX files.

Summary and Additional Resources

This guide provided comprehensive information regarding how Workspace ONE UEM secures and manages Windows 10 device communication during enrollment and after enrollment.

Additional Resources

For more information about Workspace ONE, explore the VMware Workspace ONE Activity Path. The activity path provides step-by-step guidance to help you level up in your Workspace ONE knowledge. You will find everything from beginner to advanced curated assets in the form of articles, videos, and labs.

Additionally, you can check out 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.

For more information on Managing Windows 10 Devices with Workspace ONE, see the Understanding Windows 10 Management activity path. The content in this path helps you establish a basic understanding of Windows 10 management in the following categories: Getting Started, Adoption & Migration, Device Onboarding, Configuring Policies & Baselines, Deploying Applications, Updates & Patches, Scripting & Sensors, OEM Integrations, Troubleshooting & Tools, Case-Studies & Communities.

For more information about the underlying Microsoft Protocol’s used and referenced throughout this document, refer to: [MS-MDE2]: Mobile Device Enrollment Protocol Version 2 and [MS-MDM]: Mobile Device Management Protocol.

Changelog

The following updates were made to this guide.

Date

Description of Changes

2021‑08‑11

  • Initial Release

About the Author and Contributors

This guide was written by:

With significant contribution from:

  • Saransh Bhatnagar, Senior Manager, Workspace ONE UEM Engineering, VMware

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

Filter Tags

Workspace ONE Workspace ONE UEM Document Deployment Considerations Intermediate Windows 10 Design Deploy