Safeguard Exchange for Mobile-Device Access

An increasing number of users want to get email while away from their desks. This trend is a far cry from the old days of mainframe-based email, which users retrieved through a terminal. Today's mobile handheld devices, such as Research In Motion's (RIM's) BlackBerry line, Good Technology's Good G100, various Windows Mobile—powered products, and PalmSource's Palm OS—powered Smartphones, are powerful enough to open and edit attachments and handle complex HTML messages. Additionally, a growing number of people carry cell phones that support Wireless Application Protocol (WAP), which lets even these small and relatively dumb devices access sophisticated Web-based applications, albeit at the cost of speed and functionality.

Exchange Server 2003 seeks to meet the growing demand for mobile-device access to Exchange by offering assorted products and services for limited-function devices. The two newest components in this array are Exchange ActiveSync and Outlook Mobile Access (OMA). For information about other mobile-access components in Exchange, see the sidebar "Exchange's Mobile-Computing Support."

EAS and OMA
Exchange 2003's Exchange ActiveSync data-synchronization service lets devices that run Pocket Outlook synchronize the Inbox, Calendar, and Contacts wirelessly, delivering an experience much like Microsoft Office Outlook 2003 with remote procedure call (RPC) over HTTP Secure (HTTPS) enabled. When the Always Up-To-Date (AUTD) function (labeled Up-to-date Notifications in Figure 1) is on, the device automatically synchronizes your local Inbox with the server's copy, meaning that your email is on your device when you need it. All of Pocket Outlook's functionality is available with Exchange ActiveSync as long as you can establish a wireless connection to your Exchange server. As a bonus, Pocket Outlook with Exchange ActiveSync lets you read locally cached mail offline.

Many cell phones can use WAP 2.x to talk to WAP-aware applications. Microsoft has exploited the wide availability of WAP 2.x-compatible devices by including the OMA service in Exchange 2003. OMA, which requires ASP.NET on the Exchange server, lets you establish a real-time connection with Exchange from a browser-enabled wireless Internet device, such as a cell phone. Compatible devices can access messages in the Exchange Inbox, Calendar, and Tasks folders. Unlike IMAP and Exchange ActiveSync, OMA doesn't offer offline access. The bottom line is that OMA provides a basic interface to Exchange data and is designed to minimize bandwidth usage because most WAP users pay per-unit data charges.

The first question many administrators have about OMA and Exchange ActiveSync is, "How secure are they?" Delivering adequate security on the desktop is hard enough; the thought of having to secure many autonomous mobile devices can be daunting. Let's examine the safeguards OMA and Exchange ActiveSync provide to secure communications traffic, authentication, access, and devices.

Communications Security
OMA usually uses Secure Sockets Layer (SSL) to protect its HTTP sessions from end to end. For devices that use WAP, the wireless carrier might let its network use Wireless Transport Layer Security (WTLS) protocol, which is based on the Internet-standard Transport Layer Security (TLS) protocol. WTLS is used for over-the-air communications between the device and the WAP gateway; HTTPS is used for Internet-based traffic between the WAP gateway and the OMA server. Neither the user nor the Exchange administrator controls whether WTLS is used. For the gateway to use HTTPS to your server, the WAP gateway provider must trust the certificate your server uses. If your server uses an internally issued certificate, you'll probably need to obtain a certificate from a trusted Certificate Authority (CA), such as VeriSign or Thawte.

Exchange ActiveSync's security is somewhat easier to understand. Exchange ActiveSync uses HTTPS to connect to your Exchange server, so you must open port 443 on your front-end server. In addition, you might have to consider how best to deploy your certificates to the client devices if you use a self-signed or locally issued certificate. In both cases, you can't change the default ports OMA and Exchange ActiveSync use, and you can't control whether they use encryption—they always do. Score one for "secure by default"!

Authentication
Exchange 2003 lets you control how your servers authenticate clients. Because OMA and Exchange ActiveSync are integrated with Exchange, you control and manage them much as you do IMAP, POP, and Outlook Web Access (OWA). Exchange ActiveSync clients connect to the Exchange virtual directory, just as OWA and other WWW Distributed Authoring and Versioning (WebDAV) clients do.

If you enable forms-based authentication (FBA) or require SSL to connect to the virtual directory, OMA and Exchange ActiveSync might stop working, reporting HTTP 500 errors. To be more precise, if you turn on FBA or SSL, Exchange ActiveSync will break; if you turn on SSL, OWA will break.

How much of a problem this is for your network depends on how you've configured SSL. If you enable SSL from the Internet to the front-end server, you can disable SSL on the back-end server's Exchange virtual directory, and OMA and Exchange ActiveSync will work. After all, the crucial path is really from the client to your front-end server. However, if you want to force the use of SSL on the back end, too, you need a workaround to enable Exchange ActiveSync and OMA to work properly. The exact steps required vary somewhat depending on what you're trying to do:

If you have to create a new virtual directory, you must configure Exchange ActiveSync and OMA to use that new directory instead of the default by setting the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMasSyncParametersExchangeVDir registry subkey (of data type REG_SZ) to the name of the new virtual directory. You should also add an IP address restriction in Microsoft IIS so that outside computers can't connect. Allow connections only from 127.0.0.1 (the loopback address for the local client), and you should be in good shape.

Access Control
You might not want every user to have access to OMA or Exchange ActiveSync, and Microsoft has anticipated this contingency. Remember that Exchange ActiveSync and OMA are both installed by default, but OMA is disabled for all users until you enable it in the Mobile Services Properties dialog box. These settings apply per server; in most cases, the best approach is to enable Exchange ActiveSync and OMA only on front-end servers—and only when you want those front-end servers to provide the corresponding service.

After your servers are squared away, you can allow or deny access to OMA and Exchange ActiveSync to individual users by using the MMC Active Directory Users and Computers snap-in. Open the Properties dialog box for the user's account, and click the Exchange Features tab, which Figure 1 shows. This tab shows the feature state for Outlook Mobile Access, User Initiated Synchronization (i.e., Exchange ActiveSync), and Up-to-date Notifications (i.e., AUTD). By selecting the appropriate features and clicking Enable or Disable, you can control the features that users can access. By default, users have OMA and Exchange ActiveSync access, although the OMA service is disabled by default.

Selecting those features one by one is tedious, though. To enable or disable these services for groups of users, you can use a script to stamp a value into the msExchOmaAdminWirelessEnable attribute of each affected user account's properties in Active Directory (AD). This value must be a bitmask; bits 1, 2, and 3 control OMA push, OMA browsing, and Exchange ActiveSync synchronization, respectively.

Device Security
Until now, I've ignored a rather important component: securing the devices themselves. The smaller and more expensive a gadget is, the more likely it will be lost, stolen, or broken. You'll probably lose a percentage of devices each year because of users' forgetfulness or carelessness, so you should take care to minimize potential security exposures from such losses.

For example, encourage users to employ their devices' locking features. You can set most phones and PDAs to activate a power-on PIN when the device is turned on. For extra security, many devices let you set a separate PIN to unlock the device after a specified period of inactivity. Windows Mobile 2003 devices can use an alphanumeric password; do your best to persuade those users to use such a password. Third-party vendors offer other security features, such as fingerprint readers.

Additionally, some devices (such as the Good G100 and various BlackBerry models) can be remotely deactivated. Know which field devices you can deactivate and how to do so quickly, in case a device is lost or stolen. If you encourage your users to treat their PDAs and phones like corporate credit cards—and to protect them in the same way—you'll probably hit the right balance between paranoia and caution.

Here are three things you should do immediately when a user loses a device:

Go Mobile
Exchange 2003 provides two new ways for mobile users to get email. However, this new functionality brings security risks that you must mitigate through access control, authentication, and communications security.