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 want OMA only and you want to use FBA but not SSL, don't do anything.
- If you want OMA to work with SSL enabled on the Exchange virtual directory, create an alternate virtual directory by using either Exchange System Manager (ESM) or the Microsoft Management Console (MMC) IIS Manager snap-in.
- If you want to use Exchange ActiveSync and enable either SSL or FBA on the Exchange virtual directory, use the IIS Manager snap-in to create an alternate virtual directory. Creating virtual servers from within ESM copies the "use FBA" flag from the existing server. Then, you can point OMA to the alternate virtual directory also. The Microsoft article "Cannot Access Exchange Server 2003 by Using Outlook Mobile Access When the Exchange Virtual Directory Requires SSL or Uses Forms-Based Authentication" (http://support.microsoft.com/?kbid=817379) describes the specific steps to do this.
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_MACHINE\SYSTEM\CurrentControlSet\Services\MasSync\Parameters\ExchangeVDir 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:
- Change the user's network account passwords. This precaution is essential because a device that uses Exchange ActiveSync has the user's AD password, so an attacker can (at a minimum) pose as the user.
- If the lost device is a mobile phone, notify the cellular carrier to deactivate it. Doing so makes it harder for attackers to surreptitiously use the device to attack you or as a network access tool to attack someone else. On phones based on Global System for Mobile Communication (GSM), the attacker could plug in another Subscriber Identity Module (SIM) and use the phone, albeit with a different phone number, to attack your network.
- If the user who lost the device was involved in a sensitive matter, find out which specific types of data might have been on the device. Assume that confidential information on the device will be disclosed, pull in the appropriate people (e.g., public relations, legal), and plan accordingly.
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.