How to block Microsoft's Acompli "Outlook for iOS and Android" app on Exchange 2007

The EU Parliament I.T. department has already banned its use. There are many criticisms both valid and paranoid...as well as the fanbois rants against tin-foil-wearing-anti-Microsoft folks.

Briefly explained, Microsoft acquired a company called Acompli. The Acompli mobile app has been re-branded “Microsoft Outlook for iOS and Android”. It’s being offered as a free app download for Apple iOS and Google Android.

But it is not the same as the native ActiveSync client that is built into the vanilla OS on Apple iOS and Google Android smartphones.

The Acompli mobile app uses a third-party cloud service that stores Active Directory credentials and copies of the data pulled from the Exchange account. This includes email, calendar, and contact data. Acompli/Microsoft employees also have the ability to retrieve data from their storage without notice to the data owners. Will they? Probably not. But you'd never know because they reserve the right no _not_tell you if they think it's best.

For those who have chosen to keep Exchange on-premises for maximum control, this application pokes holes in your security. More accurately, it bypasses security by getting users to voluntarily give their Active Directory credentials over to a third party. That's a no-no in most books, but the users are not clearly understanding that this could constitute a breach in security policies.

There are Exchange Management Shell objects you can access with Exchange 2010 and 2013. If you have any 2007 servers in your environment, you don't have those same options. I cobbled these steps together in a few hours. Yes, they're rough. No, I won't give you any support if you crash your Exchange server.
 

---

Shortcut

The active ingredient here is the IIS filter in Step 5.  If you already have a method to parse logs, simulate browsers, and validate IIS activity...then skip to Step 5 and make the filter.
 

---

Warnings

My intention is only to share information. Test at your own risk. If you don’t have experience, support, backups ... don’t blame me when your Exchange environment crashes and burns.

Do not try installing the Acompli app to test your new blocking policy. If you do, use a throwaway/test account, because, you’ve just given live Active Directory credentials to a third-party cloud service who stores both the credentials and the data pulled from the Exchange account. This includes email, calendar, and contact data.

In a production environment, you must warn your team and stakeholders. Consider your change management. Consider notifying users or managers before installing the block. If you have staff members in the field who are relying on this app for communication, they need to know who to contact when they're cut off.

Here goes. Sorry if it's a bit rough.
 

---

Step 1: Verify HTTPS connectivity in Google Chrome browser

Yes, Chrome. It was the easiest way to accomplish Step 2. Bear with me.

The URL is something like this: https:/[server]/exchweb

It should look like this:

---

Step 2: Emulate target app’s user agent

Control-Shift-I (as in Indigo) -- or click the ‘Settings’ icon (looks like three horizontal lines) > More tools > Developer tools

Click the ‘Toggle device mode’ icon. Looks like a miniature smartphone.

Change the ‘UA’ user-agent field to: Outlook-iOS-Android/1.0

Hit F5 or click the reload icon to reload the page. It should still work, except it’s smaller, in a 360x640 window:

---

Step 3: Parse IIS log files to look for User-Agent

If you don’t have it already, download and install LogParser from Microsoft. The current version is 2.2, and can be found here: http://www.microsoft.com/en-us/download/details.aspx?id=24659

You’ll need to do a little experimentation to get the correct file location and output. Here’s what I did. I'm no expert in LogParser queries. I just downloaded it today, did a lot of Googling, and copy-pasting. If you recognize a particular bit of text, I apologize for lack of citations. Let me know and I'll give a link/credit, or remove the offending material.

This searches for User-Agent name O[wildcard]
 

Logparser.exe -rtp:-1 "SELECT cs-uri-stem, cs-uri-query, date, sc-status, cs(Referer), cs(User-Agent) INTO User-Agent-Outlook_Report.txt FROM C:\inetpub\logs\LogFiles\W3SVC1\%.log WHERE (cs(User-Agent) like 'O%') ORDER BY cs(User-Agent), date, cs-uri-stem, cs-uri-query"

Select all Open in new window

To see a list of all User-Agents for troubleshooting purposes.
 

logparser -rtp:-1 "SELECT cs-uri-stem, cs-uri-query, date, sc-status, cs(Referer), cs(User-Agent) INTO User-Agent-All_Report.txt FROM C:\inetpub\logs\LogFiles\W3SVC1\*.log WHERE (cs(User-Agent) IS NOT NULL) ORDER BY cs(User-Agent), date" -i:iisw3c

Select all Open in new window

WARNING 1: You may want to copy your log files to another directory. Select only the most recent logs, perhaps only 2-4 hours worth. Otherwise, the parser may fail/quit or at least take a very long time to run through ancient logs that aren’t relevant.

WARNING 2: If you have a lot of Opera browser users, you might make the string more specific. Consider using WHERE (cs(User-Agent) like 'Outlook%'. YMMV, so tweak it to work best for you.

Review the output files to see that you are seeing user agents, and that it is sorted properly with User-Agents alphabetically. There are other output formats, so feel free to experiment to get CSV or HTML. For now, text was good enough for me.

If you're running into errors about TEXTLINE input format type, I did too. It was a problem with the wildcard character in the filename. If I included 4 chars plus wildcard, it would work. If I just wanted *.log , then I had to add -i:iisw3c to the end of the query, outside of the quotation marks.
 

---

Step 4: Parse IIS log files to look for rejection

You’ll need to do a little experimentation to get the correct file location and output. Here’s what I did: This searches for 404 errors, ordered by User-Agent. It’s a multi-purpose query that can be expanded for a range of errors, like all 400-series errors will use WHERE (sc-status BETWEEN 400 AND 499).
 

logparser -rtp:-1 "SELECT cs-uri-stem, cs-uri-query, date, sc-status, cs(Referer), cs(User-Agent) INTO 404Report.txt FROM C:\inetpub\logs\LogFiles\W3SVC1\u_ex150219.log WHERE (sc-status BETWEEN 404 AND 404) ORDER BY cs(User-Agent), date, cs-uri-stem, cs-uri-query"

Select all Open in new window

Review the output files to see that you are seeing some 404 errors and user agents, and that it is sorted properly with User-Agents alphabetically. At the least, there should be a bunch of 404 errors for favicon.ico files.
 

---

Step 5: Create filter in IIS

Launch IIS Manager.

Select the server running the CAS (front-end) role.

Under the section ‘IIS’, double-click ‘Request Filtering’.

Right-click, ‘Add Filtering Rule…’

Give the rule a name you’ll recognize later. There is no description field, so put it all in the Name field.

Header: User-Agent
The current user agent string is: Outlook-iOS-Android/1.0

Click OK to save it.
 

---

Step 6: Simulate connection from target app and verify blocking and logging

Go back to your Chrome browser session with the emulated smartphone. Hit F5 or click the reload icon to reload the page. It should show a 404 error page from IIS:

Now, copy the most recent log files. Re-run the LogParser query to find 404 rejections. Should look something like this:

cs-uri-stem          cs-uri-query                             date       sc-status cs(Referer) cs(User-Agent) 
                      -------------------- ---------------------------------------- ---------- --------- ----------- -----------------------
                      /owa/auth/logon.aspx url=https://[server]/exchange&reason=... 2015-02-19 404       -           Outlook-iOS-Android/1.0

Select all Open in new window

Re-run the LogParser query to show User-Agent beginning with ‘O’. Should look like this:

cs-uri-stem                                 cs-uri-query                             date       sc-status cs(Referer) cs(User-Agent) 
                      ------------------------------------------- ---------------------------------------- ---------- --------- ----------- -----------------------
                      /Microsoft-Server-ActiveSync/default.eas    User=[domain]%5C[user]&DeviceId=...      2015-02-18 200       -           Outlook-iOS-Android/1.0
                      /owa/auth/logon.aspx                        url=https://[server]/exchange&reason=... 2015-02-19 404       -           Outlook-iOS-Android/1.0

Select all Open in new window

Congratulations! You’ve verified that somebody else already connected with the target app yesterday. The second line shows your URL from the Chrome browser emulation being blocked.

As you continue to monitor the logs, you should see the user(s) who previously connected (sc-status = 200), should start getting 404 errors.

Hope this helps.