Citrix ADC – Securing Microsoft Exchange Hybrid Deployments

Reading Time: 4 minutes

Guest Blog from Julian Jakob (@jakob_davidson)

Table of Contents


As most MS-Exchange-Online migrations are ending up with one Exchange-part OnPrem – it’s called Exchange Hybrid Deployment – I was thinking about the hardening of the two commonly used exchange virtual directories, Autodiscover and Exchange Web Services (EWS), mostly for MS-Teams calendar access for OnPremises mailboxes.

Exchange-Online is using Open-Authorization (OAuth), so the first intension was to use OAuth at ADC for pre-authentication with AAA. Then I checked the following article from the MS Exchange Team

Configuring Teams calendar access for Exchange on-premises mailboxes – Microsoft Tech Community

Containing the following statement (which I commented on the thread, hoping the MS-Team will ever dig into it…)

“Autodiscover and EWS URLs should be available from the Internet. Pre-Auth is not supported. If you use some sort of publishing system, you will need to configure pass-through.”

And there’s also the following article from the F5 BigIP Support engineers, which is listed to use passthrough-auth instead of pre-auth for the selected used virtual directories Exchange Outlook Calender not visible with hybrid setup across on-prem and cloud users (

So, what’s better getting full access to /Autodiscover and /EWS without pre-authentication AND staying in the Microsoft’s supported line? Filtering using Pattern Sets on ADC. The goal is to difference between M365 servers requesting /Autodiscover or /EWS (No-AAA-Pre-Auth) and random clients from the internet requesting /Autodiscover and /EWS for their Outlook Anywhere, too (With enabled AAA-Pre-Auth) – if you’re not allowing Outlook Anywhere directly from the internet, you can bind a default LoadBalancer to your Content Switch containing a responder blocklist. (Jump directly to part three)


I’ve used the latest JSON (07/29/2021) ( from Microsoft containing all listed IP ranges of Office 365 and I’ve filtered the file, so it’s only containing:

  • IPv4 ranges (as all my ADC customers don’t using IPv6 yet)
  • Only service areas for Exchange-Online, Teams (containing S4B), SharePoint, OneDrive and the M365 common and office online ones
  • Only TCP Port 443

ATM the filtered list is containing about 38 IP ranges from Microsoft. A future goal is to automate the JSON updates to the patset on ADC, so you don’t have to maintain the entries by manual.

Part one, creating the Pattern Set and associated policy expression

Part two is about creating the content switch policies for the correct filtering. You have to create 2x Autodiscover and 2x EWS Exchange load balancing vServer on your ADC – the difference is w / wo AAA Pre-Auth and w / wo filtering on the Pattern Sets. Checkout Julian’s Exchange ADC post if you’re needing some technical details

Very important is the priority of the policy bindings to your exchange content switching vServer, the „NoAAA“ policies have to hit first!

Part three is containing to create a blocking responder page, which is hitting as the default load balancer bound to the exchange content switch OR if you’re not allowing outlook anywhere service and your IP is not listed in the PatSet, the responder action is giving you this output:


A positive side effect is to compare M365 server access with the direct internet client access via the different content switching policies. In my opinion it’s not the most secure way, but way better than putting the OnPrem exchange-host directly to the internet. I’m curious if Microsoft will change the possibilities for ADC’s regarding pre-authentication, soon.

Big thanks to Jeroen Tielen as his blog post about IP Black and Whitelisting with Citrix ADC was the missing impulse for creating this post.


If you’re having problems with free / busy query in your hybrid deployment, check your WSSecurityAuthentication, see Nod’s Blog: Office 365 – Exchange Online – Free/Busy Query from Exchange Online Mailbox to On Premises Exchange Fails (


  1. I am looking to set this up, but no where in in the this article do you actually setup the actions the NoAAA policies point to or the lb virtual servers that I assume those actions point to. I see the actions refered to as CS_Action_Exchange-AUT-NoAAA and CS_Action_Exchange-EWS-NoAAA. What is special about these items that I am missing?

    1. NoAAA links to Exchange-LB where there’s no AAA vServer (preauthentication) bound to. So the Exchange Online is able to point directly to the EWS and AUT Service, only with the active Patternset as a filter.

      The remaining access of Clients is pointing to Exchange-LB with bound AAA vServer for preauthentication.

  2. add cs policy CS_Policy_Exchange-AUT-NoAAA -rule HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ(“”)&&HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).STARTSWITH(“/autodiscover”)&&PolExpr_Allow_M365 -action CS_Action_Exchange-AUT-NoAAA
    add cs policy CS_Policy_Exchange-EWS-NoAAA -rule HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ(“”)&&HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).STARTSWITH(“/ews”)&&PolExpr_Allow_M365 -action CS_Action_Exchange-EWS-NoAAA

    add cs policy CS_Policy_Exchange-AUT -rule HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ(“”)&&HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).STARTSWITH(“/autodiscover”) -action CS_Action_Exchange-AUT
    add cs policy CS_Policy_Exchange-EWS -rule HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ(“”)&&HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).STARTSWITH(“/ews”) -action CS_Action_Exchange-EWS

    The cs_action are missing , can you please share them as well

Leave a Reply

Your email address will not be published. Required fields are marked *