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, the Configure ENS2 with SEG section in the Configure SEG as EWS Proxy for ENS topic.
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.
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.
Configure ENS2 with SEG
The following procedure describes the steps to configure ENS2 with SEG.
- Navigate to .
- Select the application.properties file and edit the file.
- Select the enable.boxer.ens.ews.proxy value and update the value to enable.boxer.ens.ews.proxy=true.
- Restart the SEG service. SEG receives the /EWS and /ews endpoints for traffic from the ENS.
Configure SEG for Authentication
If you are using basic authentication only, and the EWS endpoint is configured to allow NTLM authentication, ensure the SEG version is 2.9.0.1 and validate the remove.unsupported.auth configuration in SEG using the following procedure:
- Navigate to folder using file explorer.
- Select the application.properties file and edit the file.
- Check if the remove.unsupported.auth.for.ews value is true if NTLM authentication is enabled on Exchange, as SEG does not support NTLM connection persistence. If you do not see an entry for remove.unsupported.auth.for.ews then the SEG version is not 2.9.0.1. Ensure the SEG version is 2.9.0.1.
- Verify the SEG version and save the file.
Results: In the SEG application.properties, flag the remove.unsupported.auth.for.ews=true value to remove the unsupported www-authentication header from the EWS response to the ENS through SEG. The NTLM and the Negotiate headers are removed from the EWS response. The NTLM header as a persistent connection is not supported by SEG. The Negotiate www-authenticate header is removed in the absence of a valid client certificate, that is, when the userPrincipalname (UPN) is null. In the absence of Kerberos authentication, the Negotiate header can be considered as NTLM authentication.
