Partilhar via


Restrict iOS apps which can access to Office 365 services (ADFS required)

Merry Christmas everyone!!

Today is Christmas and finally got some time to focus on a new article I wanted to write for a while.

A lot of my Microsoft Intune customers in Japan are asking me the same question over and over again: how can I restrict the applications which can connect to Office 365? and that’s a question with lot of sense. Why? Because in Intune, we offer the MAM capacity for data loss prevention (DLP). As you might know, when you open a corporate document in a MAM enabled app like Microsoft Word, you can't paste the content of that document in a non-managed app.

Those customer are basically asking me if it is possible to restrict access to Office 365 to only Microsoft MAM enabled apps like Microsoft Outlook, Word, Excel, PowerPoint, OneDrive or Intune Managed Browser (check this TechNet link to see all the MAM enabled apps in Intune).

The answer in short is: with only Intune, you can’t but if you have a federated domain with ADFS, then there is a solution (not a perfect one) to the problem.

If you have already used ADFS and its claim rules, you know that you can create conditions based of parameters (claims) that the client presents to ADFS. Within the available claims, there’s only one which can help you identify the application which tries to authenticate to ADFS services: user agent (x-ms-client-user-agent). Btw I have done all my testing with ADFS 3.0 (Windows Server 2012 R2) but it should work the same on ADFS 2.0.

Disclaimer: I’m not an ADFS nor a security expert but I do know that it’s not a perfect solution. User agent can change and are not unique to a software vendor. Even though Microsoft apps are all using the same user agent, other non-Microsoft apps could in the future use the same user agent or even spoof the same user agent to be seen as a Microsoft apps. So if you implement this solution in production, you should know the risk you are taking.

If you want to restrict Office 365 access based on location of the client, you should take a look at the excellent TechNet article describing the ADFS rules needed to implement that.

Coming back to my user agent story, every app has an user agent. For Microsoft apps like Outlook, Word, Excel PowerPoint, OneDrive and Intune Managed Browser on iOS, they are all sharing the same user agent.

Here’s the user agent of Microsoft Outlook/Word/Excel/PowerPoint/OneDrive/Intune Managed Browser on an iOS 8.4.1 device.

Mozilla/5.0 (iPhone; CPU iPhone OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12H321

And this is an example of user agent of Safari browser on iOS 8.4.1:

Mozilla/5.0 (iPhone; CPU iPhone OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H321 Safari/600.1.4

Last example is the user agent of Chrome browser on iOS 8.4.1:

Mozilla/5.0 (iPhone; CPU iPhone OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) CriOS/44.0.2403.67 Mobile/12H321 Safari/600.1.4

You can notice the slight differences between those user agents, right? So an easy way to allow MS apps’ user agent to access Office 365 would be the following claim rule (whitelist way):

exists([Type == " https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent" , Value == "Mozilla/5.0 (iPhone; CPU iPhone OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12H321"])
=> issue(Type = "
https://schemas.microsoft.com/authorization/claims/permit" , Value = "true");

As you might notice, there’s many variable characters and numbers in the above user agent: form factor of the phone (iPhone/iPod/iPad), iOS version, webkit version, iOS build number. And all of these numbers will change when iOS will be updated or when the app itself will be updated.

To ensure that we are not affected by any of these variable in the user agent, I used regex (regular expression) to only match the other characters. Here’s an example of what an ADFS claim rule looks like with regex:

image

exists([Type == " https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent" , Value =~ "^Mozilla\/5.0 \((iPhone|iPad|iPod); (CPU|CPU iPhone) (?:OS\s*\d+_\d+(?:_\d+)?\s*)? like Mac OS X\) (?:AppleWebKit\/\d+(?:\.\d+(?:\.\d+)?|\s*\+)?\s*)? \(KHTML, like Gecko\) (?:Mobile\/\w+\s*)?$"])
=> issue(Type = "
https://schemas.microsoft.com/authorization/claims/permit" , Value = "true");

Again I repeat, this is not a perfect solution but it can help limiting potential access to Office 365 from unwanted applications. Implement this at your own risk.

PS: To find the user agent of an app, I recommend setting the default ADFS rule to deny all access in a lab environment. You also need to enable auditing of ADFS access (follow that article to enabled auditing on ADFS). Then when trying to authenticate to ADFS from an app, you will be denied (as expected) and in the security logs of your ADFS server, you will find the user agent of the application!

Additional notes for Android:

It works the same way for Android apps but there’s a difference between Office apps user agent and Intune Managed Browser user agent on this platform.

Microsoft Word for Android user agent:

Mozilla/5.0 (Linux; Android 5.0.1; GT-I9505 Build/LRX22C; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/46.0.2490.76 Mobile Safari/537.36 PKeyAuth/1.0

Intune Managed Browser for Android user agent:

Mozilla/5.0 (Linux; Android 5.0.1; GT-I9505 Build/LRX22C; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/46.0.2490.76 Mobile Safari/537.36

Comments

  • Anonymous
    January 18, 2016
    Great article!  I am going to try this out.  I've been looking for a way to do this for a while.  I've looked in the ADFS logs and not seen anything listed in the x-ms-client-user-agent string when I first started trying to find a way to do this.  I must have missed it.  Thanks again for writing this blog post! -JD

  • Anonymous
    January 18, 2016
    Hi JD, thank you for your kind comment! Have you enabled logging in ADFS? because it's not by default. I've put the link to an article explaining how to do it (jorgequestforknowledge.wordpress.com/.../enabling-auditing-of-issued-claims-in-adfs-v2-x-and-adfs-v3-x). When enabled, the access logs should appear under the source "AD FS Auditing".

  • Anonymous
    August 24, 2016
    Excellent writeup.Samir - I'm curious if you have implemented a similar solution for blocking Outlook 2016 for Mac? There's an article on technet titled "Limiting Access to Office 365 Services Based on the Location of the Client" but it doesn't seem to cover the new Mac clients or Modern Authentication.

    • Anonymous
      August 29, 2016
      I haven't tried with Outlook 2016 for Mac but since modern authentication is also available on Outlook for Mac, you should be able to find the user agent of Outlook in ADFS logs and then create a rule filtering that user agent.
  • Anonymous
    November 24, 2016
    we have ADFS with internal IP restrictions; but with claims to support mobile devices. Skype for Business ios Client connect to on-prem lync ok - but S4B clients connection to 365 for EWS to support calendar sync stops. could i use the S4B UserAgent to allow access to EWS?

  • Anonymous
    January 09, 2017
    Great Article, Now just to expand on this we are trying to get this rolled out on all IOS Platform using safari , how do you think we can get this done .this is what we are trying but it is not working.exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent", Value =~ "^(.\nMac\n*.*)$"])