A few weeks ago I had a look at some of the new features in Exchange 2010 regarding how Exchange ActiveSync (EAS) can be “locked down” or restricted to only allow certain devices to sync (as opposed to the default open-for-all configuration). While those techniques specifically targeted Exchange 2010 there are some other methods you can employ as well, and I thought I’d take a look at some of them here. Not all of them are bullet proof, but it’s interesting to have them listed nonetheless.

Self-signed root  certificate
While the recommended approach with Exchange 2007 and onwards is to use SSL certificates from a commercial CA on your internet facing services it’s perfectly ok to use certificates signed by your own CA. Windows Mobile devices are enforcing SSL trust, and will not allow the device to sync if the certificate fails validation. In other words – if you use a self-signed SSL certificate, and you don’t distribute this to the users, they will not be able to sync their devices. Seemingly a good approach, but there’s a few drawbacks.
- Since you distribute the root certificate to the users who are allowed to sync it is possible that one of these users are able to extract the certificate and re-distribute it.
- Other devices than Windows Mobile may be perfectly happy to sync with untrusted certificates. Symbian devices prompt the user to accept the untrusted cert. and will proceed if accepted by the user. iPhones will just do the sync (user-firendly remember).
Most likely the self signed approach will not help you in the long run.

Bonus tip: A very useful tool for extracting the certificate when you know the address of the server is SSLChainSaver: 
http://blogs.msdn.com/windowsmobile/archive/2008/05/18/sslchainsaver-v2-released.aspx

“Faking” the Common Name and/or hostname
A variation of the trick above is to issue the certificate to a non-resolvable address; like eas.contoso.local or possibly not even add a host record to the public facing DNS server so you can only access EAS by knowing the IP address. To make it work on a Windows Mobile device you’d add a static host name entry to the registry so the certificate will be validated even with the .local suffix. This solution will also block the basic users, but you can count on one clever user locating the loophole and telling the others all about it.

Blocking by default, only allowing specific devices
Ok, we’re not really that much closer to a real solution to the problem are we? How about looking further at Exchange itself? Exchange 2007 introduced a cmdlet that will let you “disable” EAS for new devices. This means that while EAS is available as a service. only devices you specifically allow will be able to use it. Basically a whitelisting feature. The drawback? Well, you have to manually enter the specific device ids that are allowed through another cmdlet (ok, the same cmdlet, but different parameters). So it introduces a certain administrative overhead, but if you have enough people manning your helpdesk it’s doable. Well, if you know how to extract the device id you need to enter that is. (More on this later.)

To disable EAS run the following cmdlet:
Set-CASMailbox –ActiveSyncEnabled $false –Identity user@domain.com
(You can pipe the output of a Security Group to this command to disable it for multiple users.)
To enable a specific device, for a specific user:
Set-CASMailbox –ActiveSyncAllowedDeviceIDs xyz –Identity user@domain.com

While this approach is effective I believe it’s a hassle on the admin side of things.

Installing middleware
A totally efficient approach, and one that should perhaps have been mentioned earlier is disabling ActiveSync altogether. No EAS enabled on your Exchange server – no user able to sync without permission. Or with permission for that matter Jokes aside, it is an alternative that could be worthwhile for some enterprises. If you disable EAS, and install a BlackBerry Enterprise Server for instance, only BlackBerry devices will be able to sync. Of course introducing another server into your infrastructure introduces other aspects as well – someone needs to manage it, does it support all the devices you need (?), are there more or less features than native EAS, etc. I don’t think I would implement a PIM solution purely with the intent of blocking certain devices, but it might make sense if you choose a PIM solution that will let you do more than just shuffle PIM data, and include this as part of a larger mobility strategy.

Blocking User Agent in ISA/ForeFront
If you are more gung ho than the average Exchange admin/architect maybe you have exposed your ActiveSync virtual directory directly to the dangers of the Internet. Odds are, if you’re slightly more sane that you’ve got some box wedged in between. Something like a firewall, reverse proxy or similar to put an extra hop between your domain and your WAN. While there are a number of products out there, for some reason ISA Server / ForeFront Threat Management Gateway comes highly recommended from Redmond Since ISA / TMG is able to inspect every last octet of bits that flows through it’s network interfaces you have some options available for filtering.

EAS uses HTTP as the transport protocol, and one of the details in this protocol is that the client side is supposed to report a “user agent” where it reports what kind of client it is. (This is most commonly an identifier of the browser, but in cases like custom apps, or OS components some other agent is reported.)

So how does it look? Well, it’s a silly example, but here’s how to block Internet Explorer (because that’s quick and easy to test). Normally when opening EAS in IE you’ll get an error code of 501/505. So I’ve run through the wizard in ForeFront for publishing EAS. I then edit the rule created (you have to create the rule first, it cannot be done in the wizard).
Click “Configure HTTP”.
 
Go to the “Signatures” tab and click “Add”.

I’ve specified MSIE as that is how Internet Explorer identifies itself, but you can add “iPhone”, “Android” or whatever have you here. When I try to browse the site now I get the following error:

Nice indeed. But are we happy with this? No, unfortunately not. While you have the ability to blacklist specific user agents you do not have the ability to whitelist. And you don’t really want to be updating this on a weekly basis as an admin task. Another weakness of the mechanism is that on some platforms the user might be able to modify the user agent, and then you run into a classic cat and mouse game. Now if you want to use this method it should also be combined with parsing the EAS-logs on your CAS server to know the actual user agents being used, and also try to catch the usernames of those who try to circumvent the system.

Have a look in c:\inetpub\logs\LogFiles\W3SVC1 (if running IIS in the default location). And/or parse the log files more thoroughly:
http://msexchangeteam.com/archive/2006/02/14/419562.aspx

ForeFront UAG
ForeFront is not a single product – there’s a whole family of products. A new member of the family is ForeFront Universal Access Gateway, which is currently in the RC0 stage. I believe it’s the successor to the Intelligent Application Gateway which was only available as OEM appliances (correct me if I’m wrong). I’m not exactly sure how this will position itself versus ForeFront TMG when they both hit RTM. (TMG will RTM before UAG as per my understanding.) If you want to use the DirectAccess feature in Windows 7/Windows Server 2008 R2 UAG is apparently the way to go, and it is intended as a gateway to your infrastructure as alluded to in the product name. To complicate matters further ForeFront TMG is actually a component that is used for firewall services in UAG. Still hanging on? Not me…

So why do I bring it up? Wouldn’t it be the same as the last bullet point? Yeah, well, sort of. You can publish Exchange ActiveSync through UAG as well. You’ve got more options than you can shake a stick at too, as far as I can tell. I did not however see a clever whitelist feature though, so thus far I haven’t found a compelling reason to use it. I could of course be wrong, since I am not as familiar with this product yet.

Network Level Restrictions
While EAS makes the most sense when you can access it externally, you don’t have to publish it to the whole Internet. Many mobile operators will set up a private APN for you if you ask nicely (read: ordering extra services). This means that while you are using the same GSM network as other subscribers you’ll basically have your own VLAN. There’s different implementations out there involving authenticating against a RADIUS server, connecting a dedicated router in your infrastructure that is hooked up to your operator, etc. The device is then allowed access based on a username/password combo, authenticating the IMSI number of the SIM card, or a combination.

While some mobile operators are pushing this as a good solution, and often incorrectly labeling it as mobile VPN, it also has a few drawbacks.
- It will usually cost you extra money.
- You need to standardize on one operator. (This isn’t really a drawback per se, but it’s more difficult to change operator when you’re unhappy with their service if you’re dependent on services like these.)
- It may not work properly when roaming.
- Depending on the authentication scheme it might be possible for a clever user to copy the configuration settings to a non-compliant device along with the SIM card. (Remember; this is not an authentication of the device.)
- Deployment can be tricky – you cannot expect users to handle this themselves.
- If you need to maintain an extra RADIUS server that’s more work for you.
- You may see reduced throughput, and if you’re really lucky you’ll see sporadic time-out related errors.

If you build a RADIUS filter that will let you check both IMEI and IMSI, and only allow devices you pre-approve it should work though. There are some benefits to bringing the mobile devices closer to your infrastructure on a VLAN level too, so it might be beneficial as a component in your overall strategy. As you can probably tell by now I like the concept of a grand strategy:)

In the same vein – I have heard people suggesting putting IP filters/restrictions in place. Only allow a certain range of IPs to sync, etc. Stop right there. It’s not a good idea. Don’t pursue it further – it is:
- A hassle to maintain
- Usually a large range of IPs you need to allow. If there are potentially a million other people who can have an IP in that range you’re not really restricting things.
- NAT anyone?
- Also works on the SIM level – a non-provisionable device is still non-provisionable.

Putting EAS behind VPN
Closely related to looking at the network side of things is putting EAS behind a VPN. If you’re deploying SCMDM this is an interesting scenario. Since WM 6.1 is the only OS supported by SCMDM so far it’s very effective at restricting access. A minor drawback is that you will not be able to allow other devices to sync even if you want to. SCMDM isn’t the only VPN solution out there so you can achieve similar goals with other VPN clients too. Just make sure you have a wide range of client support, and preferably a client configuration the users aren’t able to copy from one device to the other.

I really like VPNs, but unfortunately it can be troublesome to get working. IPSec is locked down on many default APNs, and SSL-based VPN for mobile device isn’t really there yet. I’d really love to see DirectAccess for mobile devices, but that’s probably still in the future. (And I don’t even know if it’s there.)

ISAPI-filter / IIS Module
We’ve been through a couple of different options by know, and they’ve all had their imperfections. Wouldn’t it be nice with a silver bullet now? Well, ok, still not there, but I did defer the most promising alternative until now. That is, it might require a little help from your friendly neighborhood programmer. If that is not a problem, it might be right up your alley.

As I said EAS traffic flows through the HTTP protocol between the client side and the server side. This means that you can filter on things like user agent, source IP address, etc. But triggering the sync itself is performed by submitting an HTTP POST request. Provided your ActiveSync is located at eas.contoso.com the POST will look similar to this:
https://eas.contoso.com/Microsoft-Server-ActiveSync/?DeviceID=1234&DeviceType=iPhone&User=andreas&Cmd=Sync
The interesting parameters are DeviceID and DeviceType, as these are the ones identifying the device itself. Now if we could filter by these properties…

Enter ISAPI. By now you’ve probably figured out if you weren’t already in the know, that ActiveSync on the server side is running on Internet Information Services (IIS) – hosted either on Windows Server 2003 or Windows Server 2008 as a web application. IIS has a concept where you can add your own plug-ins to the execution stack. In IIS 6 these are implemented as so called ISAPI filters consisting of a .dll written in C++. In IIS 7/IIS 7.5 these can be the same dlls, or a managed module written in C#. (I’m not sure of the exact distinction between an ISAPI filter, and an IIS module, but MSFT seems to be recommending the latter.) This means that before the traffic is passed on to the actual web application you can do a lookup on the DeviceID and DeviceType in a database, do a regular expression, or what best suits your given scenario. Not in the list of approved DeviceTypes? No sync for you!

Yes, it is similar to the building of access rules in Exchange 2010 that I showed in my last article, but I believe it’s more flexible “outsourcing” this to a database. And you also have the option of combining DeviceIDs and DeviceTypes to build both blacklists and whitelists. I know, most Exchange admins aren’t very open to the idea of installing extra software on their servers, but configured properly it will only affect ActiveSync, and if you don’t build too complex rules it shouldn’t be much of a performance hit either.

So, what does the DeviceIDs and Type look like? Ah, here’s where the detective work comes into play. What I have found so far:
Windows Mobile –> DeviceID = long hex value (called ExchangeID), DeviceType = PPC/SmartPhone/variation of this
iPhone –> DeviceID = IMEI, DeviceType = iPhone
Symbian E-series –> DeviceID = IMEI, DeviceType = IMEI

You can catch more through monitoring the ISA Server logs, or run Network Monitor on your Client Access Server.

You’d also need to figure out things like where to store the database (preferable on a “witness server” if you have redundant CAS servers), administration of the filter (web interface to the db?), and make some planning to make sure that you understand the implications. But I believe done right it would be smooth. Trying to add two plus two you might wonder if this is possible to implement on your reverse proxy. Yes, I believe you can. ISA/TMG has an SDK allowing you to write plug-ins, and other proxies might have SDKs too. While I’m not going to dismiss this idea entirely I believe this can be considered business logic, and more suited to perform on the application server. An ISA/TMG server should pre-authenticate users as part of the security mechanisms, but other than that it should be optimized for throughput and inspecting traffic for signs of malicious activity. Filtering authenticated users seems to me like it is better to implement at the next stage in the sync pipeline. I’m open to different takes on this however

Ok, this turned out to be a longer post than I initially thought. I believe I have given you some ideas, hopefully some methods you hadn’t already come across. (I know there’s a lot of smart people out there.) Maybe there’s more options that haven’t crossed my mind yet. Well, you know where the comments sections is if you have any input, and if I come up with any more tricks you know I’ll be telling you all about it