Securing OMA and EAS

OMA and EAS are integrated with Exchange, so they can be controlled and managed in much the same way as IMAP, POP, and OWA. The first thing to highlight is that EAS clients connect to the /Exchange virtual directory, just like OWA or other Web Distributed Authoring and Versioning (WebDAV) clients do. If you enable form-based authentication (FBA), or if you require the use of SSL to connect to the virtual directory, OMA and EAS might stop working, reporting HTTP 500 errors. To be more precise, if you turn on FBA or SSL, EAS will break; if you turn on SSL, OMA will break. How much of a problem this is for your network depends on how you have configured SSL ”you can allow SSL from the Internet to the front end, so if you disable SSL on the back end s /Exchange virtual directory, OMA and EAS will work fine. However, if you want to force the use of SSL on the back end, too, there s a workaround to enable EAS 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, you don t need to do anything.

• If you want OMA to work with SSL enabled on the /Exchange virtual directory, you need to create an alternate virtual directory via either Exchange System Manager or the IIS Manager. Exchange System Manager is much easier to use, of course.

• If you want to use EAS and enable either SSL or FBA on the /Exchange virtual directory, you have to use the IIS Manager application to create an alternate virtual directory. That s because creating virtual servers from within Exchange System Manager copies the use FBA flag from the existing server. Once that s done, you can point OMA to that virtual directory too. Microsoft Knowledge Base article 817379 describes the specific steps you have to take to do this.

If you have to create a new virtual directory, you ll need to configure EAS and OMA to use that new directory instead of the default. This requires you to set the HKLM\SYSTEM\CurrentControlSet\Services\MasSync\Parameters\ExchangeVDir key (a REG_SZ) to the name of the new virtual directory. You should also add an Internet Protocol (IP) address restriction in IIS so that outside computers can t connect ”allow connections only from 127.0.0.1 and you should be in good shape.

Enabling and Disabling Mobile Services

The first step toward securing these services is knowing their default installation state. By default, a new installation of Exchange Server 2003 will have OMA disabled and EAS enabled. You control both of these settings from the Mobile Services Properties dialog box (Figure 16-1), which is found under the Global Settings node immediately beneath the Exchange organization in Exchange System Manager. As Figure 16-1 shows, enabling OMA is a matter of selecting or clearing a simple check box. EAS support is a little more involved, because you get finer control over synchronization behavior.

Figure 16-1: You can separately enable or disable EAS and OMA in the Mobile Services Properties dialog box.

Controlling User Access to OMA and EAS

There are two ways to control which users have access to OMA and EAS. (Most of the time, organizations either enable both of these protocols or neither of them, so I tend to lump them together.) Those of you who read Chapter 15 carefully will recognize these methods , because they also apply to the IMAP and POP protocol servers:

• Enable or disable OMA and EAS access for an individual user The Exchange Features tab in Active Directory Users and Computers shows the feature state for OMA, AUTD, and EAS (Figure 16-2); by selecting the appropriate features and using the Enable and Disable buttons , you can control what they can do. By default, users have OMA and EAS access, even though OMA is disabled by default.

  
  Figure 16-2: Control individual users mobile access with Active Directory Users and Computers.

• Enable or disable OMA or EAS for a group of users To do this, you ll need to stamp a value into the msExchOmaAdminWirelessEnable attribute of each affected user s account properties in Active Directory. The following sample script (written by Ed Thornburg of Microsoft) sets this value to 0x7, which enables OMA push notifications, browsing, and synchronization. (You can also set bits 30 and 31, which allow unsupported device access and AUTD messages over SMTP, respectively).

   ' ---------------------------------------------------------------- 
   ' You have a royalty-free right to use, modify, 
   ' reproduce and distribute the Sample Application Files 
   ' (and/or any modified version) in any way you find useful, 
   ' provided that you agree that Microsoft has no warranty, 
   ' obligations or liability for any Sample Application Files. 
   ' 
   ' Copyright (C) 1996-2003 Microsoft Corporation 
   ' ---------------------------------------------------------------- 
   
   
   On Error Resume Next 
   ' ---------------------------------------------------------------- 
   ' bind to Users,DefaultNamingContext 
   ' ---------------------------------------------------------------- 
   Set objRootDSE = GetObject("LDAP://rootDSE") 
   Set objUsers = GetObject("LDAP://cn=Users," & 
   objRootDSE.Get("defaultNamingContext")) 
   ' ---------------------------------------------------------------- 
   ' recurse the collection of User objects and 
   ' set msExchOmaAdminWirelessEnable to 7 if currently null 
   ' ---------------------------------------------------------------- 
   For Each objUser In objUsers 
   strname = objUser.Get("name") 
   WScript.Echo "name: " & strname 
   strWirelessEnabled = objUser.Get("msExchOmaAdminWirelessEnable") 
   If strWirelessEnabled = "" Then 
   objUser.Put "msExchOmaAdminWirelessEnable", "7" 
   objUser.setinfo 
   End If 
   strWirelessEnabled = objUser.Get("msExchOmaAdminWirelessEnable") 
   WScript.Echo "msExchOmaAdminWirelessEnable: " & strWirelessEnabled 
   & vbcrlf &_ 
   ' ---------------------------------------------------------------- 
   Next 
   set objRootDSE = Nothing 
   set objUsers = Nothing 

Unlike with IMAP and POP, you can t turn off the virtual server because these services are provided through IIS; you also can t block their network ports at the perimeter, because this traffic is indistinguishable (at the protocol level) from ordinary HTTP, WebDAV, and Outlook Web Access traffic.