Blocking the Outlook App for iOS or Android from Exchange Using IIS or TMG

We’ve recently seen the arrival of Microsoft Outlook for iOS and Android. The software was created by Acompli and then acquired by Microsoft, and I suppose rebranded. As it happens it’s a pretty good mail client, but, unfortunately it has a nasty trick up its sleeve that happens to violate my employer’s acceptable use policy – and many other company’s security policies too. It turns out that when you sign-in to the app and add an account, it automatically stores the Exchange user credentials and server name in a service running on Azure. They are then used to poll the exchange CAS servers for mail updates on behalf of the user, and to perform a sync when requested. The issue here is that the data is retrieved for the user by a service and not by the app on their mobile device, whether or not the device is on. This was first reported here and later again here.

To see this in action all you have to do is look at the IIS logs on the CAS servers and look for the User-Agent in the traffic, looking specifically for “Outlook-iOS-Android/1.0” – you’ll see usernames in the query strings and a bunch of unusual IP addresses – which it turns out are Azure datacentre IPs. So there we see traffic coming from Azure using credentials that users have provided and retrieving mail data. So the credentials are being stored at rest somewhere completely unexpectedly. Apparently they are encrypted, doubley-so, but just storing those credentials is the worst thing possible!

OK what to do about all this. Answer: tell your users to remove their accounts from the app and then stop using the app for Exchange related usage. That would be easy if everyone did as they are told but that’s not always the case. We can do this with IIS Request Filtering (explained at the end) but what I did as well was make use of signature blocking in TMG to prevent all traffic with the specific user-agent provided by the app.

Block Using TMG

1. Open your TMG server configuration MMC (or ISA if you’re still using that for some crazy reason) and find the rule that covers the path for the ActiveSync folder in OWA, and right-click it.
2. Select “Configure HTTP”, open that and switch to the “Signatures” tab.
3. Click Add… and create a new signature as shown below.
Name: Outlook for iOS/Android 1.0
Description: Block Outlook for iOS/Android 1.0
Search in: Request headers
HTTP header: User-Agent:
Signature: Outlook-iOS-Android/1.0

4. Then click ok and Apply the change.

You can then monitor your traffic going through TMG and should start to see ActiveSync traffic being blocked where the Outlook-iOS-Android/1.0 user-agent is involved. You can actually detect exactly who is using the app in your environment by monitoring looking at the logs again for the same user-agent. Looking at the query string you should be able to see the usernames in the ?User= part of the string. You can then use these to communicate with the relevant people in your organisation to hopefully prevent help desk calls.

If you want to prevent ‘new’ sign-ups using this client without worrying about existing users so as to not interrupt your users and again cause more unnecessary work for your help desk you can be more selective with your blocking and a probably create a new rule that exclusively filters based on the &Cmd=Provision component of the path as well as the signature:

/Microsoft-Server-ActiveSync?User=*&Cmd=Provision

The rule would need to be an allow rule and simply specify the path as above, along with the http signature to block, but prevent authentication. This should stop new users from being able to connect. I haven’t tried it but I think the theory is sound. You might be better of doing it with IIS Request Filtering though as that’s a lot more powerful…

Block using IIS Request Filtering

If you wanted to use IIS Request Filtering instead this would be both easier and harder, as of course you need to implement it on all of your CAS servers, but of course it doesn’t rely on you having TMG, and you’ll always have IIS.

1. Find the IIS applets for the “Microsoft-Server-ActiveSync” virtual folder and double-click the “Request Filtering” applet on the right.

2. In the Request Filtering options choose the Rules tab and click “Add Filtering Rule…” from the actions pane.

3. Add new rule using the following options:

  • Name: Agent Rule
  • Scan url: unchecked
  • Scan query string: checked
  • Header: User-Agent
  • Deny Strings: Outlook-iOS-Android/1.0

Then just repeat that for each CAS server.

If you’d like more details here’s a useful blog post discussing uses for Request Filtering in IIS: http://www.peterviola.com/blocking-sql-injection-with-iis-request-filtering/

Event id 1021 when phoning a UM extension redirected to voicemail

We recently started trying to configure the UM role in Exchange 2007 and had to buy an AudioCodes IP gateway to translate traffic from our legacy PBX into SIP traffic for the Exchange server.
Very early on we ran into an issue where we if we diverted a phone to the Exchange UM pilot number (i.e. re-direct all calls to voicemail) then if we called that phone we would get rejected.

A lot of diagnostics and tracing later, we discovered that the calls were being rejected by the UM server, and it was throwing a 1021 warning in the Application log. The message reads:
The Unified Messaging server rejected an incoming call with the ID “<call-ref-number>@<um-server-ip>”. Reason: “The Unified Messaging server cannot find a valid UM hunt group for “<extension>” associated with UM IP gateway “<um-server-ip>”.”

So the UM server was trying to find a hunt group for the extension that we were calling, and was thinking there wasn’t one configured. We did however have a hunt group configured! We had deleted the default hunt group on the ip gateway, and configured a new one with the pilot number as the pilot identifier…big mistake…

It turned out that when you configure a hunt group in UM, if you give it any Pilot Identifier number at all, that is the only number that it will be triggered for. So what you have to do is give it a blank Pilot Identifier! Trouble is you can’t do that, when you make a new hunt group the dialog will not let you create it without typing something in. So what do you do?

Well the answer is, delete and recreate the IP Gateway configuration object in the UM IP Gateways tab of the UM Organization Configuration section. That’s all you have to do! What happens is that when you create a new IP Gateway object it automatically creates a default hunt group with a blank pilot number – and that’s what we want.

Once you’ve done that you’ll be able to call the redirected phone and leave voicemail. Phew. Working UM system!

Lesson learned today: don’t configure things in UM if you don’t know what they’re for…

Exchange 2007 SP2 has been released

And so to the insignificant clash of tiny mouse sized symbols Exchange 2007 Service Pack 2 has finally been released: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID;=4c4bd2a3-5e50-42b0-8bbb-2cc9afe3216a

According to a little very sketchy investigation I’ve done there’s a schema change and support for PowerShell 2 – in fact they are recommending it! According to this blog post (link) PowerShell 2 is already in Windows 7 and Server 2008 R2, and sure enough if you run powershell and type $psversiontable and that proves it 🙂
[yes i’ve been running Win7 Enterprise x64 RTM for the last 2 weeks, hehe]

Using Outlook to send email from a different domain than the default

Q: What if you want to send email using Outlook connected to an Exchange server, but you want to send it ‘from’ an address which is different to the one you normally receive?! For example you have your exchange server ‘receiving’ email to user@domain1.com and user@domain2.com but you can only send email with messages coming from user@domain1.com … what do you do when you want to send from user@domain2.com?!

A: All you have to do is add a new POP3 account to your email accounts and set the SMTP server to the exchange server’s name, the pop3 server to anything, e.g. localhost. Make sure you set your email address to the new one you want email to appear to come from. Finally you need to set the send/receive settings so that the new account only sends email, and doesn’t try to receive it. That’s because if it tries to receive it’ll fail because we’re actually faking this account and there is no need to receive messages.

Once the account is made and the settings are changed you’ll be able to create a new email and see a new button in the new message toolbar allowing you to change the account. That email will then appear to come from the other address!

Easy really…but so many people don’t seem to think of this!
It all relies on the fact that exchange servers can act as smtp relays so long as the machine you’re using to connect to it can authenticate, if that works then exchange automatically lets you send any email you want. If you can’t authenticate then usually it’ll stop you, unless the settings have been relaxed of course.