Protecting an email server is one of the hardest jobs in IT security. The incredible growth in remote email access makes this job even harder. Now, admins must defend the email server without having full control over the computers connecting to it. Complicating matters, at a time when organizations are encouraged to subscribe to Exchange Online, many still want to run their Exchange servers on-premise. If your organization is invested in on-premise Exchange server, is there a way to enable remote email access in a way that doesn’t turn security into a problem?

Balancing these issues of security and service provision isn’t easy. Technology moves on, and today’s email server security solutions aren’t always adapted to the on-premise world.

For years, receiving email meant having the right email client. For most business users, that meant running Outlook.

Today, the rise of remote working has tipped the balance away from standalone applications. Increasingly, users access the same messaging and calendaring functions through a web browser (without noticing any difference).

Users win because they can access their email from any device without loading a special application. Organizations win too because they can enable secure remote access while centralizing email access security and data management.

In Windows, web access to Exchange email depends on a technology called Outlook on the Web (formerly Outlook Web Access, or OWA).

Note, if you're managing email servers running Exchange Server 2013 or 2010, you're using the Outlook Web App.

Learn how to secure remote access to an Exchange 2013 mailbox

Outlook on the Web is your email program if you're using Microsoft 365, or Exchange Server 2016 or 2019.

OWA works either by connecting to Exchange Online, a Microsoft 365 cloud-based email system, or an on-premise Exchange server accessed through Microsoft’s web server, IIS, with authentication handled by a server role called Exchange Client Access Service (CAS).

In the Microsoft 365 scenario, it’s just a web access capability that admins turn on as part of their subscription. However, with an on-premise Exchange server, organizations must configure the backend infrastructure and security for themselves.

Despite the market shift to cloud services such as Exchange Online, many customers opt to keep their Exchange email system on-premise and focus on securing access to on-premises Microsoft Exchange server.

Why? Motivations include everything from avoiding the cost of Exchange Online subscriptions, the need to keep email data onsite for compliance reasons, and a need to retain on-premise Exchange to ensure compatibility with legacy applications.

The catch is that while on-premise OWA offers a lot of convenience, it opens an organization to much more security risk.

The targeting of online and on-premise OWA has been a consistent theme for years but has recently become more sophisticated.

In 2023, Microsoft revealed that a group identified as Storm-0558 had gained access to the email systems of at least 25 organizations by forging authentication tokens used by online OWA and Outlook.com.

In the 2021 “ProxyLogon” attack, ten different cybercrime groups used exploits for four zero-day vulnerabilities to target OWA on an estimated 250,000 on-premise Exchange servers across the world. One of the most serious attacks to affect OWA, numerous organizations were affected, including many SMBs.

Unquestionably, on-premise Exchange is now a weak spot cybercriminals have marked out as a target.

With on-premise servers, OWA is a public connection, which means that all an attacker needs to target the service is a server address (discovered through research) and the credentials for a single user account.

Credentials are easy for criminals to phish or to brute force. And when they do, criminals get an open window into the heart of an email system. This means they can attack your organization from the inside:

• To conduct internal phishing attacks on other employees.

• To search for other credentials, such as those used to access the corporate VPN.

• To exploit security vulnerabilities of Microsoft Exchange Server to obtain a “remote shell” (the ability to execute commands remotely).

• To exploit vulnerabilities in the OWA itself as a bridgehead to compromise domain controllers and other internal infrastructure.

And there’s always the chance that criminals might create a replica of an OWA login page to try and phish employees not looking closely enough at what they’re clicking on.

Exchange is a complex piece of software that is getting long in the tooth, which makes it more likely to have high-risk vulnerabilities. Even when these are identified, patching them can be difficult. Sometimes, customers prefer to stick with older and more vulnerable versions.

The targeting of OWA doesn’t always get enough attention, but the broader issue remains clear: OWA is a security risk because the backend infrastructure on-premise email access depends on is aging and sometimes complex to administer.

Multi-factor authentication (MFA) is the logical option for protecting OWA access. By adding a second factor of authentication before granting access, you can hugely reduce the risk of credential compromise.

However, assessing MFA for OWA options can be confusing. In short, there is no single Microsoft-native answer to the problem. Usually, Microsoft pushes organizations towards Active Directory Federation Services (AD FS) MFA or to Entra ID’s Application Proxy, each of which has drawbacks depending on an organization’s infrastructure and Microsoft licensing.

The problem with these native solutions is they add a lot of complexity to the network, which makes it harder for admins to manage OWA access.

UserLock, by contrast, is designed to make implementing MFA for on-premise AD networks as simple as possible.

Once you install the UserLock server, that’s it. No need for additional infrastructure. The MFA agent for OWA is installed on the existing IIS server, and you can set up how MFA presents itself to the user in the UserLock server console.

To authenticate to OWA, your user enters their usual Windows credentials just like they usually do. Then, the OWA agent sends them an MFA prompt. This can be via a 2FA push notification, a code from an authenticator app, or using an MFA security key or token such as a YubiKey or Token2.

Importantly, admins get a lot of granular control over MFA prompts such as time of day, device location, user, group, and organizational unit (OU). As a bonus, in addition to OWA, UserLock supports multiple session types, including MFA for VPN, IIS, SaaS, Remote Desktop (RDP & RD Gateway), VDI sessions, Wi-Fi, and Windows MFA.

Read more about how to secure remote access to an Exchange mailbox with UserLock