Yesterday, Microsoft announced the immediate availability the Outlook for iOS and Outlook for Android preview. These apps are the former app named Acompli, which was acquired by Microsoft in December, last year. It is unlikely that Microsoft will develop and support two similar apps, so one can assume the new Outlook app will replace the current OWA for iOS and OWA for Android (or just OWA for Devices) apps.
The app isn’t without a little controversy:
- The app stores credentials in a cloud environment from Amazon Web Services for e-mail accounts that don’t support OAuth authorization.
- The app makes use of a service sitting between the app and your mailbox. This service acts as a sort of proxy (hence it requires those credentials), fetching, (pre)processing and sending e-mail. In some way this is smart, as it makes the app less dependent on back-end peculiarities, using a uniform protocol to communicate with the proxy service.
- The app does not distinguish between devices (device identities are assigned to your account, which makes sense since the app uses a service to retrieve and process your e-mail).
- The app does not honor ActiveSync policies, like PIN requirements. While true, this app is not an ordinary Exchange ActiveSync client.
You can read more about this here and here.
In all fairness, when the app was still named Accompli, nobody cried foul. But the app is now rebranded Outlook and property of Microsoft, so it seems this made the app fair game. I hope Microsoft is working behind the scenes to make the new Outlook app enterprise-ready, and I’m sure it won’t be long before we see the app’s services move from AWS to Azure. The whole outrage in the media also seems a bit misplaced, as Connected Accounts in Exchange Online, which will retrieve e-mail from a POP or IMAP mailbox, will also store credentials ‘in the cloud’.
It is recommended to treat the app as a consumer app for now, and you may want to block the app in your organization. I have written on how to accomplish blocking or quarantining faulty iOS updates before. However, in those articles I used the reported OS version to block or quarantine devices. The Outlook app proxy service reports itself as “Outlook for iOS and Android” as device model when querying your mailbox, allowing us to use the DeviceModel parameter for matching.
The cmdlet to block or quarantine the new Outlook app in Exchange 2010, Exchange 2013 or Office 365, is:
New-ActiveSyncDeviceAccessRule –QueryString 'Outlook for iOS and Android' –Characteristic DeviceModel –AccessLevel Block
or, to quarantine:
New-ActiveSyncDeviceAccessRule –QueryString 'Outlook for iOS and Android' –Characteristic DeviceModel –AccessLevel Quarantine
For examples of alternative blocking methods using TMG or F5, check this article. If you need to specify the user agent string, use “Outlook-iOS-Android/1.0” (or partial matching on “Outlook-iOS-Android” to block future updates of the app as well).
As goes for all mobile devices in enterprise environments, as an organization it may be better to test and aprove devices and OS versions rather than to be confronted with mobile apps with possible faulty behavior after an update or which may violate corporate security policies.
Pingback: Outlook App for iOS & Android | The clueless guy
Worked like a charm. Out test user received the following:
Your phone won’t be able to synchronize with the server via Exchange ActiveSync because of an access policy defined on the server.
Information about your mobile phone:
Device model: Outlook for iOS and Android
Device type: Outlook
Device OS: Outlook for iOS and Android 1.0
Device user agent: Outlook-iOS-Android/1.0
Device access state: Blocked
Device access state reason: DeviceRule
LikeLike
Pingback: NeWay Technologies – Weekly Newsletter #132 – January 30, 2015 | NeWay
You can block the app on the Exchange-server-side, but this does not block the user to:
1) dl and install the app from store
2) provide his/her domain credentials in the app
So all that can be achieved by this article is, that after the user successfully downloaded+installed the app, provided his/her secret corporate identity in the app which leaks it to a 3rd party (as I could understand from your article, this is the only part why the community cried wolf), it will simply not sync to exchange successfully. So the credentials have already been leaked to the 3rd party.
Or am I missing the key point, why everybody in the community looks at this app like to a serial killer?
LikeLike
Or maybe the only problem of everybody is that this MS app does not respect their own in-house EAS policies?
LikeLike
That could be an issue, as the app converses with the ‘service’ – the services doesn’t care about PIN settings etc. It should however be not difficult to pass those required options from the service to the app, so the app can check compliance and adjust settings when required.
LikeLike
I placed a ticket with the Exchange team as more of an FYI. They never heard of it and the solution was the best they could offer at the time. They did pass it up to the Exchange devs and engineers. Hopefully something like this app gets put through a better review process.
LikeLike
For non-OAuth, the ‘service’ requires your device to decrypt the stored credentials, used to access the configured mail service. More info here: https://www.yammer.com/itpronetwork/#/Threads/show?threadId=492725777
LikeLike
Pingback: The UC Architects » Episode 47: A New Outlook on life
Thanks for this post. I’ve heard colleagues raving about the app but hadn’t yet dug into the details enough yet to see the controversial details, so I appreciate your tips.
LikeLike
What would be the query string for blocking the original Accompli app? As I understand, it will remain available, but is never going to be fixed.
LikeLike
Pingback: Weekly IT Newsletter – January 26-30, 2015 | Just a Lync Guy