Monitor compliance of the client with the ENS2 environment so that ENS2 together with SEG V2 can block or unblock a client depending on the compliance criteria of the client.

Background

Currently, when a mobile device is enterprise wiped or removed from the Workspace ONE UEM console, the client unregisters from the ENS2 environment. For example, when an enterprise wipe command is sent to iOS Boxer the device tries to unregister until it is successful. However, this is not an ideal scenario as there is a dependency on the device to unregister from the ENS2 environment.

Integration with SEG V2

The SEG V2 protects the email configuration of the client and enables MEM functionality by monitoring the compliance of the device against the configuration in the Workspace ONE UEM console. With the integration of ENS2 and SEG V2, you can block request to a device and control the client, based on the compliance criteria specified in the Workspace ONE UEM console. The following is a high-level diagram showing the interaction between ENS2 and Exchange with SEG V2 as the proxy.

In addition to the compliance scenario, you can use SEG V2 as a proxy when the Exchange Web Service (EWS) endpoint is not publicly available. The EWS proxy allows devices to subscribe to the EWS subscriptions through the SEG V2 server instead of publicly exposing the EWS endpoint.

SEG V2 supports both cloud and on-premises ENS deployments. SEG V2 listens to the EWS traffic from ENS using the EWS endpoints. SEG applies the MEM compliance policies on the incoming requests and proxies the requests to Exchange. See, Configure ENS2 with SEG.

Supported Exchange Web Service Authentication Methods for SEG Proxy

The Exchange Active Sync (EAS) authentication method used with Boxer must match the EWS authentication method as ENS implicitly uses the authentication method used by Boxer. SEG as EWS proxy supports basic authentication, certificate-based authentication (CBA) with KCD, and modern authentcation (OAuth) types and does not support the New Technology LAN Manager (NTLM) authentication type.

Certificate-based authentication using KCD is supported. If your deployment utilizes CBA using KCD, SEG accquires the Kerberos token (from KCD) required for the Exchange authentication. The authentication method for EAS and Exchange Web Service (EWS) protocol must match for SEG to work correctly.

For more information, see the Configure SEG V2 Compliance for Email Notification Service topic in the Secure Email Gateway (SEG) V2 guide.

Supported Servers for Exchange Web Service and ActiveSync

If you have different fully qualified domain name (FQDN) for Exchange Web Service (EWS) and ActiveSync endpoints, it is recommended you upgrade to SEG version 2.12 or later. In this SEG version, you can provide a different hostname and uncomment the ews.email.server.host.and.port=https://example.com:443 property for EWS flows.

Note:

If you provide a different hostname, SEG still uses the server timeout, ignoreSslErrorsWithExch, and other settings from the EAS email server configuration provided in the MEM configuration for the email server client. If the EWS server is using self-signed certificate then you need to add the self-signed certificate in the Java trustStore before the SEG installation or you need to rerun the SEG installer.

For SEG versions before 2.12, the only option available is to have two different MEM configuration and two different SEG servers to proxy traffic. One SEG can serve one email server address or FQDN. However, if EWS and ActiveSync endpoints are hosted on the same email server address or FQDN, same SEG server can proxy both EWS and ActiveSync traffic.