Best Practices for Deploying a Mobile Messaging Solution

6/2/2010

Best practices for deploying a mobile messaging solution on your corporate network are recommendations that will help you ensure the smooth operation of, and provide a high level of security for, your mobile messaging solution.

Network Configuration

Regardless of the network configuration you implement, there are some best practices that will strengthen your mobile messaging solution.

Best Practice: Use Front-end and Back-end Configuration for Exchange Servers

A front-end and back-end configuration is recommended for multiple-server organizations that use Exchange ActiveSync, Outlook Web Access (OWA), Post Office Protocol (POP), or Internet Message Access Protocol (IMAP), and that want to provide HTTP, POP, or IMAP access to their employees. In this architecture, a front-end server accepts requests from clients, and then proxies those requests to the appropriate back-end server for processing. The front-end and back-end architecture allows the front-end server to handle the Secure Sockets Layer (SSL) encryption, thus enabling the back-end servers to increase overall e-mail performance. This configuration scales well and provides a measure of security by limiting access to the front-end server.

Securing the messaging environment also involves disabling those features and settings for the front-end server that are not necessary in a front-end and back-end server architecture.

For more information about front-end and back-end server architecture, see "Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology" at https://go.microsoft.com/fwlink/?LinkId=62643.

Best Practice: Configuring your Firewall for Optimal Direct Push Performance

Direct push technology requires an established connection between the server and the client. No data is sent over this connection unless there is e-mail or data to be transmitted, or the device needs to reestablish its connection with the server. This means that the maximum length of the connection is determined by the lowest network timeout in the path between the device and the server.

With good network coverage, the maximum timeout will be determined by the connection timeout that is enforced by the firewalls that deal with Internet traffic to your Exchange front-end servers. If you keep the timeout very low, then you will force the device to reconnect several times, which will quickly drain its battery. The following illustration shows the recommended firewall settings.

As a best practice, you should adjust the connection timeout of your firewall and any other network appliances in the path to ensure that direct push functionality works efficiently. In order to optimize battery life, we recommend a timeout period of 30 minutes.

For a technical discussion of direct push technology, see Understanding the Direct Push Technology in this document.

Security: Authentication and Certification

Security for communication between the Exchange server and client mobile devices can be increased by using SSL for encryption and server authentication, and by using Web publishing to protect incoming traffic.

The following best practices will help you build a more secure mobile messaging solution.

Best Practice: Use SSL for Encryption and Server Authentication

To protect outgoing and incoming data, deploy SSL to encrypt all traffic. You can configure SSL security features on an Exchange server to verify the integrity of your content and the identity of users, and to encrypt network transmissions. The Exchange server, just like any Web server, requires a valid server certificate to establish SSL communications.

Windows Mobile 5.0-based devices are shipped with trusted root certificates. Check with your device manufacturer for a current list of the certificate authorities that shipped with your device. If you obtain a root certificate from one of the trusted services, your client mobile devices should be ready to establish SSL communications with no further configuration. If you create your own certificates, you must add that certificate to the root store of each mobile device.

For more information about obtaining server certificates, see “Obtaining and Installing Server Certificates” in the Exchange Server 2003 Client Access Guide at https://go.microsoft.com/fwlink/?LinkId=62628.

For more information about root certificates for mobile devices, see Appendix D: Adding a Certificate to the Root Store of a Windows Mobile-based Device.

Best Practice: Determine and Deploy a Device Password Policy

You can now use Exchange Server SP2 together with Windows Mobile 5.0-based devices that have the Messaging and Security Feature Pack help you to configure a central security policy that requires all users with mobile devices that access the Exchange server to protect their device with a password.

Within this central security policy, there are several attributes you can configure, including the length of the password (the default is four characters), the use of characters or symbols in the password, and how long the device can be inactive before it prompts the user for the password again. One of these policies is the wipe device after failed attempts option, which allows you to specify whether you want the device memory wiped after multiple failed logon attempts.

Once you have determined your device security policies, you must deploy them by using Exchange System Manager’s Mobile Services Properties. When your users connect their device to the Exchange server, sign in, and accept the security policies, your policies will be sent to the device. The policies will not be enforced until they have been accepted on the device by the user. You can set the interval at which the device security policies will be automatically refreshed on the device.

For more information on setting security policies, see "Configuring Security Settings for Mobile Devices" in Step 6: Configure and Manage Mobile Device Access on the Exchange Server.

Best Practice: Use Web Publishing with Basic Authentication

For many companies the use of Basic Authentication over an encrypted channel (SSL) is an acceptable security requirement. These companies can further secure their mobile deployment by leveraging ISA 2004 or ISA 2006 to Web publish the Exchange Server 2003 front end servers.

The benefit with leveraging ISA's Web publishing capabilities is that ISA has built in logic to distinguish well-formed Exchange ActiveSync requests so it can help protect the Exchange front end server from malicious attacks.

As a best practice, Web publishing is easier to implement and provides a higher level of security than server publishing, although larger companies that are planning to use client certificate-based authentication must implement the latter.

Server publishing, also known as tunneling, refers to network/transport-layer protection, whereas Web publishing, also known as bridging, refers to application-layer protection. Web publishing is only possible when SSL is terminated on ISA Server 2004. Because ISA Server 2004 only sees encrypted traffic, it cannot perform tasks such as protocol hygiene that require it to analyze the contents; thus ISA Server 2004 only offers protection based on the network/transport layers.

Best Practices for Using Certificate-based Authentication

For certificate-based authentication to work correctly with Exchange ActiveSync, the enterprise firewall must be configured to allow the Exchange front-end server to terminate the SSL connection. For this reason, Web publishing will not work with certificate-based authentication with ISA Server 2004. However, ISA Server 2006 supports Kerberos Constrained Delegation, allowing you to choose either Web Publishing or SSL Bridging from the ISA machine to the Exchange front end server.

An overview of the process for deploying certificate-based authentication is provided in Appendix A: Overview of Deploying Exchange ActiveSync Certificate-Based Authentication.

Microsoft has provided several tools to help an Exchange administrator configure and validate client certificate authentication.

For more information about the Exchange ActiveSync Certificate-based Authentication tool, see the Tools for Exchange Server 2003 Web site at https://go.microsoft.com/fwlink/?LinkId=62656.