Many companies and users consider mobile access to Exchange data an essential feature.  Exchange ActiveSync (EAS) is very popular as it allows this access and many devices have licensed and implemented EAS (including Windows Mobile).  Some companies use remote servers to access Exchange data and push it out to their mobile clients that aren't EAS enabled. Of course these mobile access options can be a little concerning when you think about the security implications. Evaluating these devices (and servers) to make sure they comply with data protection policies is a necessary step for a lot of companies that want to protect their messaging data.  This post will details some of the options available to companies that want to limit access to a specific set of supported devices. 

The first question we usually get is, "How do you stop unapproved devices and servers from accessing Exchange data?"  In general, I hear people talk about three ways to block devices:

  1. Use an ISAPI filter (Not recommended)
  2. Set policies that only the devices you care about can implement (Better)
  3. Block the devices at the firewall (Recommended!)

Let me describe each method in a bit more detail.

Custom ISAPI filter:
Since creating a custom ISAPI filter is both time consuming (you have to write custom code) and not a best practice, I'm not going to talk too much about it except mentioning that it is a possible solution. More details can be found here for those interested in exploring this option.

Policies as a blocking agent:
Using policies is a very easy way to do this (by unchecking the box titled "Allow non-provisionable devices" (image below) and then setting a policy that the particular device doesn't support. A list of which policies are enabled with which version of the server (and thus which generation of clients) is listed below. You may need to test a device to see which version of the policies are implemented as it varies by licensee). 

The challenge with this method is that many of today's devices are upgradable and thus may implement a policy in the future while still not providing the security you want (for example, if you want to make sure the device and storage memory are encrypted by at least 128-bit encryption (WM 6+ uses AES 128-bit encryption for storage card encryption but another device might simply do 40-bit encryption).  Because of this discrepancy, it is important to understand what devices are connecting to your network, and which ones can connect, so that you can decide if your organization is ok with this level of control.

Using ISA Server 2006 to block unwanted clients:

Finally, you can block at the firewall.  This is by far the best solution and is really easy to implement with ISA Server.  Below, I list out, and describe, the steps of how to configure your ISA server so that you can block by device type (using the User-Agent string of the device to identify and block it), and by server type (using the IP address range of the server).

Blocking by User-Agent String in ISA Server 2006:

Blocking a particular device from accessing EAS is easy to do if you filter by the device's User-Agent string at the firewall.  You can create a rule for each device type you want to block. 

In ISA Server you should already have an EAS rule set up (if not follow the wizard that the "Publish Exchange Web Client Access" takes you through).  Simply right click on that rule (pictured below) and then select "Configure HTTP".

From here, you'll get the below dialog to appear. Make sure you select the last tab named "Signatures".

When you hit OK you will go back to the main ISA Server screen but at the top it will ask you if you want to apply or discard the changes you made. (see below)  When you accept the change you are done.

Some mobile access methods work though an Internet service as opposed to directly from the device itself.  This method might be of concern to certain organizations because they have no idea what devices are connecting to their servers, how many devices are using the service or what control (policies) they have on the phone (in many cases, none at all).  These services usually have users enter their login and password and then save that on a remote server.  The remote server then logs into OWA for that user, scrapes out the information and then pushes the data down to the user's device.  In these cases, user credentials and data have left the organization and there is no control over it, or even knowledge of where it is. 

From the mail ISA screen, click on the "Create Access Rule" link. (shown below)

This will bring up a wizard that will take you through the process.  In this case we will block the fictitious servers of "Bad Site".  On the first page you will Name the rule; let's say we call it "Block Bad Site".

On the next screen we will be asked if we want this to be an Allow or Deny rule.  Since we want to keep these servers from accessing our Exchange Server, we will select Deny.

The next screen will ask us what traffic we want to block.  This is where the wording can be a bit tricky if you're not familiar with ISA Server.  In this case you want to choose "All outbound traffic".

You now need to define who this rule applies to.  Select "Add" if the group you want isn't already listed (for this example I'll assume nothing has been created or set up yet).

You will get a dialog that lets you pick who you want to apply their access rule to; select New and choose Computer Set as we are going to specify a range of IP addresses.

 

Now we need to name this new computer set (we'll call it Bad Site Servers for this example).  You can also add a description in the bottom of the dialog if you want.  Then click "Add" and select "Address Range".

 

You now can specify the address range of the server.  If the service you are blocking has more than one range of IP addresses, you will enter more than one of these (we'll go through an example of two).  You need to enter a name and the starting/ending IP addresses (shown below is just an example).  The description is optional.  Then click OK.

You can repeat this process (clicking on Add and adding another address range) as many times as there are Address ranges.  Below you can see our example has two IP address ranges.  When all of them are entered, click OK.

You will now notice that in the "Add Network Entities" list (under Computer Sets) you have the set you just defined (Bad Site Servers in this case).  Select the new Computer Set that you defined, click Add, then click Close.

Your access rule now applies to the computers you specified (in this case the Computer Set of Bad Site Servers).  You can add additional sources if you wish or click Next to move on.

You now need to define the destination for this traffic.  In this case, ISA Server (localhost) is the destination of this traffic.  Select Add to bring up your options to make this selection.

Under Network, you can select Localhost, then click Add and then click Close.

In this case Localhost is our only destination so we can select Next.

Now select who this applies to add "All Users" and then click Next.

You're done creating the access rule.  Just click Finish to take you back to the main ISA Server view.

When you hit OK you will go back to the main ISA Server screen but at the top it will ask you if you want to apply or discard the changes you made. (see below)  When you accept the change you are done.

The following dialog will appear once your changes have been applied.  Click OK.

You're done.  Below you can see that there is now a new firewall policy rule that you created to block the server you didn't want to access your site.

Note: In general, "Deny" rules should precede any "Allow" rules, although there are exceptions to this. You will need to be familiar with ISA Policies Best Practices to understand the fine points of ISA rule definition.

And there you have it; how you can block by device type (User-agent string) and how you can block by server (IP address).  New devices and services come online all the time so it's tough to have a comprehensive list but some of the more common User-Agents are:

Symbian devices: "Symbian" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader

Motorola: "mot-" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader

Samsung: "sec-" or "samsung" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader

LG: "lg-" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader

Siemens: "sie-" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader

Nokia Devices: "Nokia" http://discussion.forum.nokia.com/forum/showthread.php?t=83267

BlackBerry Devices: "BlackBerry" http://na.blackberry.com/eng/developers/resources/journals/mar_2007/profile.jsp

Apple Devices: "Appl" (no e on this one as Device ID starts with Appl so this covers all cases) Note: if you just want to block only the iPod Touch, or only the iPhone, you can just block on "iPod" or just "iPhone". http://forums.macrumors.com/showthread.php?t=361166

Some of the common Servers that try and access Exchange Server are below (with links to their docs that list their server IP address ranges):

BlackBerry Internet Service: http://www.blackberry.com/btsc/articles/644/KB11036_f.SAL_Public.html

Good Mobile Messaging (GoodLink): http://www.goodlink.com/documentation/GoodAdminGuide_exchange.pdf

For those that want more info on HTTP filters in ISA server, there are a lot more detail here.

- Adam Glick

Share this post :