If you are looking at cloud services for your organisation, it is likely you have had a conversation with your security and network teams about what part a proxy service is going to play. If you’ve not had that conversation yet, there’s a good chance you will soon… Now before I get too much into this, let me just say; if you can get away without the use of an outbound proxy when implementing Office 365 or Azure services, then don’t use one. Implement a next-gen firewall, like a Palo Alto or similar and be on your happy way.

Don’t use a proxy if you can help it

Microsoft’s position is fairly clear on the proxy support front; they support a proxy service in flow, but they don’t recommend it.

There’s a bunch of reasons I’ve seen where you may need to continue to use a proxy however, at least in the short to medium term, if not longer, reasons might include:

  • Tenant Restrictions are a requirement for your organisation.
  • There is no default route in your internal network
  • Public DNS resolution is disabled from your internal network

If you fall into the “I need a proxy server” category, there are some additional considerations you need to be aware of and consider:

Proxy service load

The proxy server needs to be configured to handle the additional load. When you’re looking at service load you need to be considerate of CPU and memory utilisation, as well as the obvious network throughput requirements.

Port exhaustion is another thing to think about if you’re a larger organisation, though not a problem specific to the use of a proxy, you could well press the 64,500 port limit when you start to add up the client connections generated from an end point consuming Exchange Online through an Outlook client, Microsoft Teams, OneDrive and SharePoint Online, as well as Office 365 Groups, Planner, Stream, etc, etc, and multiply these by the number of concurrent end users you have within your organisation.

Proxy authentication considerations

Authentication needs to be handled differently in some cases too:

Cloud based proxy services

If you are using (or thinking about using) a SaaS based proxy service, you have some additional things to think about. A SaaS based proxy reduces the amount of infrastructure you require on-premises and service capacity management effectively becomes outsourced to the provider. It also may well align to an organisational “Cloud First” strategy.

A public SaaS service might mean however, that you are sharing public IP addresses with other customers of the service. That is, the IP Address that your clients appear to be originating from (from the perspective of Azure AD and Office 365) is the Proxy Service IP addresses.

This shared IP Address becomes a problem if you are looking at using trusted locations and source IP Addresses as part of a conditional access policy configuration to enforce multi-factor authentication (MFA) for all connections outside the corporate network for example. If you decide to trust the IP Addresses used by the cloud proxy service, you will be allowing anybody who consumes that same cloud proxy service to connect to your tenant without requiring MFA…

This article isn’t intended to be a deterrent or an argument to not use a proxy service (though again I’ll repeat, if you don’t need to use one, don’t) hopefully though it’s highlighted some of the considerations and problem spaces which I’ve come across in my travels in this space.