Secure access to email from mobile devices is one of the main drivers behind any organization's mobility management initiative. Deciding on the proper email strategy is often a key component of any XenMobile design. XenMobile offers several options to accommodate different use cases, based on security, user experience, and integration requirements. This article covers the typical design decision process and considerations for choosing the right solution, from client selection to mail traffic flow.
Client selection is generally at the top of the list for the overall email strategy design. You can choose from several clients: Citrix Secure Mail, native mail that is included with a particular mobile platform operating system, or other third-party clients available through the public app stores. Depending on your needs, you can possibly support the user communities with a single (standard) client or you may need to use a combination of clients.
The following table outlines design considerations for the different client options available:
This section discusses the three main scenarios and design considerations regarding the flow of mail (ActiveSync) traffic in the context of XenMobile.
Scenario 1: Exposed Exchange
Environments that support external clients commonly have Exchange ActiveSync services exposed to the internet. Mobile ActiveSync clients connect through this externally facing path through a reverse proxy (for example, NetScaler) or through an edge server. This option is required for the use of native or third-party mail clients, making these clients the popular choice for this scenario. Although not a common practice, you can also use the Secure Mail client in this scenario. By doing so, you benefit from the security features offered by the use of MDX policies and management of the app.
Scenario 2: Tunneled via NetScaler (micro VPN and STA)
This scenario is the default when using the Secure Mail client, due to its micro VPN capabilities. In this case, the Secure Mail client establishes a secure connection to ActiveSync via NetScaler Gateway. In essence, you can consider Secure Mail to be the client connecting directly to ActiveSync from the internal network. Citrix customers often standardize on Secure Mail as the mobile ActiveSync client of choice. That decision is part of an initiative to avoid exposing ActiveSync services to the internet on an exposed Exchange Server, as described in the first scenario.
Only managed (MDX wrapped) apps can use the micro VPN function. Therefore, this scenario does not apply to native clients. Even though it may be possible to wrap third-party clients with the MDX Toolkit, this practice is not common. The use of device-level VPN clients to allow tunneled access for native or third-party clients has proven to be cumbersome and not a viable solution.
Scenario 3: Cloud-hosted Exchange services
Cloud-hosted Exchange services, such as Microsoft Office 365, are becoming more popular. In the context of XenMobile, this scenario may be treated in the same way as the first scenario, because the ActiveSync service is also exposed to the internet. In this case, cloud service provider requirements dictate client choices. The choices generally include support for most ActiveSync clients, such as Secure Mail and other native or third-party clients.
XenMobile can add value in three areas for this scenario:
- Client wrapping with MDX policies and app management with Secure Mail
- Client configuration with the use of an MDM policy on supported clients (native, such as TouchDown)
- ActiveSync filtering options with the use of XenMobile Mail Manager
As with most services exposed to the internet, you must secure the path and provide filtering for authorized access. The XenMobile solution includes two components designed specifically to provide ActiveSync filtering capabilities for native and third-party clients: XenMobile NetScaler Connector and XenMobile Mail Manager.
The use of XenMobile NetScaler Connector provides ActiveSync filtering at the perimeter, by using NetScaler as a proxy for ActiveSync traffic. As a result, the filtering component sits in the path of mail traffic flow, intercepting mail as it enters or leaves the environment. XenMobile NetScaler Connector acts an intermediary between NetScaler and the XenMobile Server. When a device communicates with Exchange through the ActiveSync virtual server on the NetScaler, NetScaler performs an HTTP callout to the XenMobile NetScaler Connector service. That service then checks the device status with XenMobile. Based on the status of the device, XenMobile NetScaler Connector replies to NetScaler to either allow or deny the connection. You may also configure static rules to filter access based on user, agent, and device type or ID.
This setup allows Exchange ActiveSync services to be exposed to the internet with an added layer of security to prevent unauthorized access. Design considerations include the following:
- Windows Server: The XenMobile NetScaler Connector component requires a Windows Server.
- Filtering rule set: XenMobile NetScaler Connector is designed for filtering based on device state and information, rather than user information. Although you may configure static rules to filter by user ID, no options exist for filtering based on Active Directory group membership, for example. If there is a requirement for Active Directory group filtering, you can use XenMobile Mail Manager instead.
- NetScaler scalability: Given the requirement to proxy ActiveSync traffic via NetScaler: Proper sizing of the NetScaler instance is critical to support the added workload of all ActiveSync SSL connections.
- NetScaler Integrated Caching: The XenMobile NetScaler Connector configuration on the NetScaler uses the Integrated Caching function to cache responses from XenMobile NetScaler Connector. As a result of that configuration, NetScaler doesn't need to issue a request to XenMobile NetScaler Connector for every ActiveSync transaction in a given session. That configuration is also critical for adequate performance and scale. Integrated Caching is available with the NetScaler Platinum Edition or you can license the feature separately for Enterprise Editions.
- Custom filtering policies: You might need to create custom NetScaler policies to restrict certain ActiveSync clients outside of the standard native mobile clients. This configuration requires knowledge on ActiveSync HTTP requests and NetScaler responder policy creation.
- Secure Mail clients: Secure Mail has micro VPN capabilities which eliminate the need for filtering at the perimeter. The Secure Mail client would generally be treated as an internal (trusted) ActiveSync client when connected through the NetScaler Gateway. If support for both native and third-party (with XenMobile NetScaler Connector) and Secure Mail clients is required: Citrix recommends that Secure Mail traffic does not flow via the NetScaler virtual server used for XenMobile NetScaler Connector. You can accomplish this traffic flow via DNS and keep the XenMobile NetScaler Connector policy from affecting Secure Mail clients.
For a diagram of XenMobile NetScaler Connector in a XenMobile deployment, see Reference Architecture for On-Premises Deployments.
XenMobile Mail Manager is a XenMobile component that provides ActiveSync filtering at the Exchange service level. As a result, filtering only occurs once the mail reaches the exchange service, rather than when it enters the XenMobile environment. Mail Manager uses PowerShell to query Exchange ActiveSync for device partnership information and control access through device quarantine actions. Those action take devices in and out of quarantine based on XenMobile Mail Manager rule criteria. Similar to XenMobile NetScaler Connector, XenMobile Mail Manager checks the device status with XenMobile to filter access based on device compliance. You may also configure static rules to filter access based on device type or ID, agent version, and Active Directory group membership.
This solution does not require the use of NetScaler. You can deploy XenMobile Mail Manager without changes routing for the existing ActiveSync traffic. Design considerations include:
- Windows Server: The XenMobile Mail Manager component requires you to deploy Windows Server.
- Filtering rule set: Just like XenMobile NetScaler Connector, XenMobile Mail Manager includes filtering rules to evaluate device state. Additionally, XenMobile Mail Manager also supports static rules to filter based on Active Directory group membership.
- Exchange integration: XenMobile Mail Manager requires direct access to the Exchange Client Access Server (CAS) hosting the ActiveSync role and control over device quarantine actions. This requirement might present a challenge depending on the environment architecture and security posture. It is critical that you evaluate this technical requirement up front.
- Other ActiveSync clients: Because XenMobile Mail Manager is filtering at the ActiveSync service level, consider other ActiveSync clients outside the XenMobile environment. You can configure XenMobile Mail Manager static rules to avoid unintended impact to other ActiveSync clients.
- Extended Exchange functions: Through direct integration with Exchange ActiveSync, XenMobile Mail Manager provides the ability for XenMobile to perform an Exchange ActiveSync wipe on a mobile device. XenMobile Mail Manager also allows XenMobile to access information about Blackberry devices and to perform other control operations.
For a diagram of XenMobile Mail Manager in a XenMobile deployment, see Reference Architecture for On-Premises Deployments.
The following figure helps you distinguish the pros and cons between using native email or Secure Mail solutions in your XenMobile deployment. Each choice allows for associated XenMobile options and requirements to enable server, network, and database access. The pros and cons include details on security, policy, and user interface considerations.