Exchange Online Disables New Inbound Connectors

Restriction forces Customers with New Tenants to Ask Microsoft Support to Enable Inbound Connectors

In an unannounced change, Microsoft recently disabled the ability of new Exchange Online tenants to activate newly-created inbound connectors. The text in the inbound connector FAQ (refreshed on 15 February) says:

“When you create an Inbound connector of OnPremises type manually, you may see the warning message Inbound connector for this service offering is created in a disabled state. Contact Support to enable it.”

The FAQ goes on to say that the customer must contact Microsoft support and provide a business justification for why their tenant needs to use an inbound connector. Microsoft attempts to reassure everyone by saying “Legitimate usage is approved, and the connector is enabled by our service engineers.” I’m sure that’s true, if you manage to speak to a level 1 support engineer who knows about why Microsoft disabled inbound connectors and understand what to do to release the block.

The EX505293 Incident

The problem with creating and updating connectors surfaced in incident EX505293 (January 27). Microsoft determined the root cause to be “A recent change to the service introduced a regression that may have prevented some admins from creating or modifying Exchange email transport connectors” and applied a fix that was operational by February 6, 2023. Because the Exchange Hybrid Connection Wizard (HCW) creates connectors, it was affected by the problem.

The EX505293 incident for inbound connectors
Figure 1: The EX505293 incident for inbound connectors

Microsoft doesn’t describe the precise nature of the fix in EX505293, but it seems like it allows tenants to create new connectors (in a disabled state). Moreover, the text in EX505293 indicates that the restriction applies only to tenants created from 2023 onwards. Microsoft’s FAQ doesn’t mention why they’ve clamped down on newly-created tenants, but it’s possible that it’s easier for an attacker to spin up a new tenant and create connectors to do bad things than to break in and compromise an existing tenant to take over its connectors.

Good Reasons Exist to Disable Inbound Connectors

Good reasons exist for why Microsoft should block inbound connectors. First, an inbound connector is not required for normal mail flow. The usual reason is that an organization wants to use a third-party solution to process their email. For instance, you might want to route messages through a third-party service to apply corporate email signatures before sending the messages to their final destination. Many of the specialized email signature ISVs like Code Two Software use inbound connectors to bring traffic back into an organization after inserting appropriate email signatures into messages.

Second, attackers who compromise a tenant might create connectors to route email through their services in an attempt to either use the tenant to send spam or to inject malware into user mailboxes (see this report about an attack on a Microsoft 365 tenant). Placing newly-created connectors into an inactive state until the owning tenant justifies the use of the connector closes off this attack vector.

I don’t know why Microsoft decided to restrict newly-created connectors. My gut feel is that something happened to cause immediate action, such as emerging evidence of a new attack technique involving connectors. We won’t know and Microsoft won’t say. Such is the nature of the security war between attackers and defenders playing out every day across IT infrastructures.

The Effect on ISVs

Even if closing off an attack vector stops attackers dead, doing so without due consideration of legitimate usage by ISVs is bad practice, especially when Microsoft didn’t warn ISVs or announce the change in a post in the EHLO blog, post a notification to the Microsoft 365 message center, or publish plans as a Microsoft 365 roadmap item. The change appeared without warning, perhaps to surprise potential attackers. It certainly surprised the affected ISVs.

Instead of being able to install their products and configure everything needed to make their software work, ISVs are now forced to perform a partial installation and ask their customers to contact Microsoft support to enable the disabled inbound connector. Microsoft has left customer-facing ISVs in an invidious position.

Not Good Business

I don’t criticize anything Microsoft does to protect Exchange Online against attack. Too many people depend on Exchange Online to risk potential compromise of user mailboxes. My criticism is entirely focused on the total lack of communication since Microsoft introduced the change referred to in EX505293 and fixed in early February. Operating in a vacuum is good for no-one, especially when Microsoft leaves ISVs out to dry and doesn’t tell them why their code no longer works.

Failure to communicate is always bad for business. It increases costs for ISVs and creates friction between ISVs and their customers. It generates an increased number of calls (and cost) for Microsoft Support to deal with. It slows business productivity where the cloud is supposed to speed things up. It’s a great example of a solution that makes perfect sense when sketched out by engineers on a whiteboard that runs headlong into problems in the real world. All in all, even if it fixed a potential security hole, forcing customers to go to Microsoft support to justify their use of a connector is a poor plan that Microsoft snuck in without saying anything to anyone.

Microsoft might say that they made the change because they want to protect Exchange Online customers. I accept their bona fides, but I expect better from the world’s largest software company, especially in how they deal with ISVs. After all, ISVs help the Microsoft cloud work better for Microsoft customers. They can’t do that if Microsoft changes the rules without saying anything.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

14 Replies to “Exchange Online Disables New Inbound Connectors”

  1. Presumably this is just limited to creating/enabling new connectors? i.e. assume re-running an existing HCW or adding IPs into an existing connector would not be impacted?

  2. It may actually be worse than just not being able to create connectors. With Exclaimer, the “old” interface gives an error when trying to add the connectors, but on the “new” interface, the process fails the first time, but if you repeat it, the connector and rules are actually added in 365, it just blocks outgoing emails…

      1. They aren’t disabled in the sense that we know from the console, but in the back end somehow, aren’t they? When I got the connectors added from Exclaimer they showed to me as though they were enabled. Disabling connectors is one thing but in this state of being able to have connectors added yet being disabled in the back end somewhere which causes transit issues is more than just lack of communication.

      2. Actually I think the connectors that Exclaimer is trying to create and either failing or for which there is some hidden block by Microsoft are Outbound connectors and not Inbound in this instance. They pass outgoing emails through the Exclaimer smarthost.

  3. The resolution is to use the new “Partner Organization” to connect to a 3rd party. I just got off a Teams call with MS support showing me this. Maddening there’s no documentation on this yet.

    1. There’s some work ongoing to make specific arrangements for ISVs that will allow them to automate the process for the connectors that they need to install. I’m waiting to hear reaction from the ISVs.

    2. I was told after-the-fact that an integrated email security provider (like Tessian, Egress, Trustifi, etc) do in fact need to use the “on-prem” type and not Partner Org.

      That said, they are ok enabling the connectors as long as the supplier/provider/3rd Party supports unique certificates per customer and there is no exception, per the MS support engineer I exchanged messages with.

  4. I just delivered an over 500 users migration including Exchange Online. Surprise surprise a new tenant was used. It’s 4th day today since I raised it with Microsoft, having been pulled from pillar to post. No one knows nothing about this.

    Very unhappy. I had to disable on the fly Exclaimer signatures for now as this is going nowhere.

    There is no process for handling requests of this type at MŚ and it makes it so frustrating.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.