Jaa


Why we recommend not using proxy with Office 365

Edited to include reference to optimize endpoint category.

 

We still have a lot of customers using web proxies for Internet access. Sometimes it is just a legacy, sometimes a way of controlling Internet access and other times, a network requirement (the network does not have a default gateway to the Internet). The idea of using proxies came from a time we had limited Internet bandwidth: We needed a way to minimize network usage and a local cache was the perfect idea. Things have changed since then and proxies evolved into content filters and other cool stuff. What didn't change was the fact that they keep handling network requests for their users.

One important thing, however, changed a lot. If we had static content in the web at the beginning, today we deal with dynamic and adaptive content, with data being exchanged between applications other than web browsers. So, the local cache loses most of its purpose.

Now imagine you procured a service for your company and you trust your service provider. Trust and reputation are really important here. If you trust your service provider will not tamper with your data, snoop around it nor provide your users access to inappropriate or distracting content, then the content filter loses its purposes in this scenario as well.

Sizing is another potential problem. Remember that the proxies are usually a group of computers and you have to pay for them; hardware, software, space, maintenance, operation, support, electricity... Nothing is free, right? Let's say you have just the amount of proxies you need to handle your daily requirements with a small safety margin. And you have just purchased Office 365 and are planning to deploy it within the next 90 days. Are the proxy servers able to handle the additional load? A load that is intrinsically made of dynamic content (I see my mailbox, you see yours).

If now you have better Internet services, dynamic content, a trusted service provider... why would you use a third party to intermediate all your communication with that service provider? That's my point today. It does not matter if we are talking Office 365, Dynamics, Azure or whatever other service you are using, you should be able to talk directly with that service provider without paying more than you have to.

Being a tad more technical

Whenever a device behind a proxy needs something hosted in the web, it will request the proxy to fetch the data and it will do so, based on its rules. It might be able to fulfill the request from its local cache or it will get it for the user and potentially cache the content. End of transaction.

Now, when you open your Outlook client to access your mailbox in Exchange Online, it will open some transactional sessions (request, fulfill, done) and other persistent connections. The number of persistent connections will vary from case to case, but I can say that I usually have between 20 to 30 total TCP connections for three mailboxes in my MAPI profile, with one Exchange Online Archive, two shared mailboxes a bunch of Office 365 groups and few shared calendars. Ok, I am not a good example... people at Microsoft tend not to be good examples, so let's say an average user will keep 4 persistent sessions on Outlook. 4 times the number of users you have, all of them at the same time, all the time, hogging the proxy resources.

Considering proxies are not usually designed for persistent connections and the possibility that your web proxy was not sized for the additional load Office 365 (or any other cloud service), they might become a bottleneck.

Real life example

A few months ago, I helped an FTC customer devising a remediation and deployment plan for Office 365. I remember we spoke about the impact of using web proxies with Office 365 and advised against it. Nevertheless, customer consulted their partner and decided to go with the proxy: They were told the proxy (and content filter, in their case) would be able to handle the additional load. Guess what? It didn't.

Customer came back to Microsoft asking for help because the Office 365 performance was not meeting the initial expectations. It didn't take long to isolate the problem on the content filter they were using.

I presented the findings along with the recommendation of not using proxy with Office 365. If they wanted to keep using proxy, fine. But not for Office 365, not for the service providers you trust. And at the end, after discussing the issue with network and security teams and presenting the same arguments you see here, they decided to bypass the proxy for Office 365.

At the bare minimum

All the Office 365 endpoints are categorized as “Optimize”, “Allow”, or “Default”, as you can see at https://aka.ms/o365ip. At the bare minimum, you should avoid proxy for the Optimize category.

The endpoints in the Optimize category are responsible for handling the most sensitive Office 365 network traffic and represent over 75% of the Office 365-related traffic. I mean sensitive to latency, performance and availability. And they are all hosted in our datacenters. E.g. this is where Outlook connects to get your mailbox data, capisce?

There are extensive clarification and guidance for each category at https://aka.ms/pnc. The time reading the article is a time well spent, I assure you.

If you need help clarifying the reasons why you should not use proxy between your users and Office 365, leave a comment. And if you are an FTC customer, ask one of us for help. We will get you there!

Comments

  • Anonymous
    August 25, 2017
    The comment has been removed
    • Anonymous
      August 25, 2017
      Thanks for pointing that out, that's a valid scenario. In this case, keeping the proxy might be the best choice. I just don’t think you should consider it the only choice. Not right from the beginning.I also believe this kind of issue goes beyond DLP: DLP is just a tool, so you may consider other things to tackle the root of the problem: Data classification (as simple as possible), user education... Then you go DLP. But I guess you have been there already.At Microsoft, we are changing the way we classify our data: From HBI, MBI and LBI to Non-business, Public, General, Confidential and Highly Confidential. The former three ones we use to tag data not meant for public disclosure. Then we apply the right IRM policies that prevent data leak even before it reaches the endpoint.If you, or any company, believe using proxy is the best way to conduct your business, that’s ok. My point is just that it should not be considered the “only choice”. Almost nothing is for everyone in IT ?EM
      • Anonymous
        February 23, 2019
        I am a CISO with a global financial institution. I am not keen to implement SSL Interception and Header Modifications with a proxy to restrict personal tenant access. What is the "other choice"?
    • Anonymous
      August 28, 2017
      May be a Conditional Access Policy will help you here.
  • Anonymous
    August 30, 2017
    Great article
  • Anonymous
    August 30, 2017
    Hi Euclides! I have applied firewall rules to bypass proxy server as you explained here. However, sometimes I face outlook access problem because O365 IP address are not allowed in bypass firewall rules (probably MS added new servers or change network address). So, what is the trick to not have this kind of issue anymore?
    • Anonymous
      August 31, 2017
      Hello, LeandroThe easiest way to keep up with the datacenter IP changes is to build your firewall rules around the names, not the IP addresses.We usually update the IP/URL lists before changing the service. So, you can also minimize the risks by keeping an eye on the article Office 365 URLs and IP address ranges.Thanks,EM
  • Anonymous
    November 08, 2017
    The comment has been removed
  • Anonymous
    November 16, 2017
    The comment has been removed
    • Anonymous
      November 01, 2018
      @Felippe, overall, MSFT does not recommend using a proxy server for Office 365 traffic as the title of this blog post states. The article you mentioned would be one of the scenarios where setting up a proxy server is needed, although still not recommended for customers that don’t need to setup tenant restrictions.