HAFNIUM Highlights the Problem with Removing the Last Exchange Server

Unless you have been living under a rock for the last week, you could not have missed that the Microsoft 365 world has been abuzz with worry after Exchange Server 2010-2019 succumbed to zero-day exploits, believed to being used by a group known as HAFNIUM. These exploits are allowing an attacker to compromise Exchange and forcing IT Pros to stay up all night pushing patches.

Microsoft swiftly made available patches for up-to-date versions of Exchange, along with comprehensive guidance and tooling for discovering whether your environment could be compromised; and followed up quickly with patches for older versions of Exchange that aren’t running supported Cumulative Updates.

These patches are crucial whether you are running Exchange Server to host your mailboxes, or just have a single Exchange Server used for Hybrid recipient management post-migration.

Security experts and Microsoft executives have been quick to rightly point out that if you can move to Exchange Online, then you should do so.

If you are running Exchange Server to host your mailboxes today, based on the discussions I’ve had with other IT professionals, it is highly likely that if you could, you would move mailboxes to Exchange Online. It is widely accepted that for most organizations, Exchange Online is the best option. Therefore, I’m not going to labor that point.

Unfortunately, though, every organization that uses Microsoft 365 and uses Azure AD Connect to synchronize their Active Directory must keep an Exchange Server running to manage recipient attributes to be fully supported by Microsoft.

It’s time for Microsoft to get serious about removing the last Exchange Server

The last seven days have shone a light on Exchange, and in particular, the last Exchange Servers that continue to run in many organizations. It’s probably fair to say Microsoft will already be considering how they can finally crack this problem without further delay but if they are not, they should be.

Microsoft documented as early as 2012 that they don’t have a solution for removing the last Exchange Server, and as you can see from the comments on the Exchange Team Blog at the time, customers have been clamoring for a solution since then, if not earlier.

Current Microsoft documentation clearly states this too, explaining that while you run Hybrid Identity, the Exchange Admin Center and Exchange Management Shell (which require Exchange Server) are the only supported tools that can be used to manage recipient attributes synced from the local Active Directory.

Official Microsoft documentation states you must keep an Exchange Server, however great you are with ADSIEdit

For many customers though, removing the last Exchange Server wasn’t a high priority.

Firstly, consider that until recently, Exchange 2010 and above were considered reasonably secure – to such a degree that Microsoft was confident to say if “you operate a secure and well managed Windows/Exchange Server – you have a more secure environment than you think. Adding pre-authentication and layers of networking complexity in front of that buys you very little extra, if anything.”. That was posted back in 2013 (in relation to TMG), and for around seven glorious years, most people agreed with that perspective. In the last year though, we’ve seen several security issues in Exchange, culminating in last week’s advisories.

Secondly, remember that even after moving to Exchange Online, older applications, multi-function-copiers, fax solutions, and more needed to be able to relay SMTP via an unauthenticated (and in many cases unencrypted) connection. Exchange Server remained a great option for taking plain SMTP and then relaying it onward to Exchange Online using a Send Connector secured by TLS.

That is not to say Microsoft has done nothing to attempt to arrive at a solution. At Microsoft Ignite 2017, in breakout session “Thrive as an Enterprise in Exchange Online”, a potential solution was outlined by Microsoft:

Several years ago Microsoft explained a potential solution

As you can see though, the solution isn’t simple. This is for good reasons – just changing the source of authority for mail-related attributes, and leaving the remaining attributes within Active Directory to become stale, creates technical debt for customers and leaves a potential problem brewing for the future.

Working on many Google Workspace migrations to Microsoft 365 has taught me that even with the best of intentions, people don’t clean up these attributes left behind and they become a problem at some point in the future.

The other option that Microsoft hasn’t, to my knowledge, proposed is to build-out an on-premises extension to Active Directory for recipient management. Long-time Exchange admins will remember Exchange 2000 and 2003 used an extension for Active Directory Users and Computers to achieve this; however, this required the Recipient Update Service running (or quite often – not running, with frustrating results) to push changes. Tasks, such as updating Email Address Policies would not be possible using an AD object attribute tool, unless it incorporated the complex logic Exchange uses.

Therefore, Microsoft has been correct to look for a good solution rather than a tactical solution.

But, the search for a solution seemed to move further away from the one that appeared to be tantalizingly close in 2017.

By Microsoft Ignite 2020, in the session Exchange – Here, There and Everywhere”, Microsoft was transparent about the situation, explaining that despite best intentions a solution is still somewhere over the horizon, and requires several different teams’ involvement:

“The one piece of news unfortunately is – there really isn’t any news, and I’m sorry to have to say that to you. We genuinely understand that many of our customers – all of our customers, in fact, who’ve moved all their mailboxes to the cloud, but keep the source of authority for AD and identities on premises, they have to keep Exchange around just for recipient management.

We completely understand that’s difficult and expensive to do, and we are doing our utmost to get rid of that.

It’s a complicated problem, though, and there are several different teams involved and there’s some complexities and it’s taking us some time to work through it.

We definitely do have a solution in mind, and we’re working towards it, but I’m hoping that Spring Ignite 2021 we’ll have some more news on that, but for now, we’re committed to solving the problem – I can assure you.”

Last week at Spring Ignite 2021 there was little in the way of news in this area, or indeed any Exchange-related content, however it is likely minds were focused on more pressing issues.

As Microsoft moves past patching exploits, hopefully, engineering efforts will be focused on finally, once and for all, putting a solution together to remove the last Exchange Server that many organizations are still running. After the hectic week caused by HAFNIUM, Microsoft needs to quickly find a pragmatic solution to the last Exchange Server dilemma; the solution doesn’t need to be perfect but any assistance at this point will be warmly welcomed.

Related Topics:

  • Exchange Server
  • Office 365
  • BECOME A PETRI MEMBER:

    Don't have a login but want to join the conversation? Sign up for a Petri Account

    Register
    A nine-time MVP, author and speaker at conferences including Microsoft Ignite and TechEd, Steve has been working with Microsoft products for over 20 years, and writing about the earliest iterations of what’s now Microsoft 365 for a over a decade. Since it launched into preview Steve has been helping organizations to plan, deploy and manage Microsoft Teams, and currently works for award winning Microsoft partner Content + Cloud in the UK as a Principal Technology Strategist, helping customers define their digital transformation plans and getting hands-on in Teams, Exchange and Identity projects.

    More Articles by Steve Goodman