How UserLock solves the Outlook on the Web (OWA) MFA puzzle
Learn how UserLock solves the Outlook on the Web (formerly OWA) MFA puzzle for on-premise Active Directory environments.
)
)
)
)
)
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?
When a workforce goes remote, so does email
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.
How Outlook on the Web (OWA) solves this remote access security problem
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.
The need to secure on-premise Exchange
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.
OWA is now a big target for hackers
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.
OWA compromise: the nightmare scenario
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.
What makes on-premise OWA so risky?
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.
Is MFA for OWA the answer?
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.
UserLock makes on-premise OWA MFA easy
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.
Implementing UserLock MFA for OWA
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
MFA is essential to secure OWA
Anyone giving users email access via OWA should implement MFA by default because the risk of not using it is now simply too great.
Passwords are incredibly vulnerable to theft and brute force attacks. Attackers know this, and the evidence from real-world incidents shows that they have started targeting networks where MFA is not in use.
To undermine remote email, attackers need only compromise one set of credentials. This fundamental weakness turns any access not using MFA into low-hanging fruit.
MFA — any MFA — is known to reduce the risk of credential compromise, so why isn’t it universally applied by default? The short answer is for on-premise email servers, doing so can quickly become technically complex and even expensive. Microsoft’s native tools mean implementing MFA for OWA requires additional software and expertise, which puts off admins looking for a simple solution for OWA access security.
The issue of managing complexity has long dogged the rollout of MFA: everyone agrees it’s a good idea, but making it happen is often easier said than done.
UserLock is an elegant way out of this OWA MFA implementation puzzle. Designed to meet the needs of MFA in on-premise networks, it can also integrate MFA security across many connection types in addition to OWA.
Organizations can support secure remote access to on-premise exchange without resorting to convoluted solutions or risking security. Importantly, UserLock allows you to do this without having to upgrade or replace your existing infrastructure.