This article is now out of date
Multi-factor authentication (MFA), that is the need to have a username, password and something else to pass authentication is possible with on-premises servers using a service from Windows Azure and the Multi-Factor Authentication Server (an on-premises piece of software).
The Multi-Factor Authentication Server intercepts login request to OWA, if the request is valid (that is the username and password work) then the mobile phone of the user is called or texted (or an app starts automatically on the phone) and the user validates their login. This is typically done by pressing # (if a phone call) or clicking Verify in the app, but can require the entry of a PIN as well. Note that when the MFA server intercepts the login request in OWA, there is no user interface in OWA to tell you what is happening. This can result in user disconnect and stops the use of two-way MFA (receive number by text, type number into web application type scenario). Therefore to that end, MFA directly on the OWA application is not supported by the Microsoft Exchange team. Steps for setting up ADFS for Exchange Server 2013 SP1 or later are at https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx. Once this is in place, you need to enable MFA for ADFS rather than MFA for OWA. I have covered this in a separate post at http://c7solutions.com/2016/04/installing-azure-multi-factor-authentication-and-adfs.
To configure Multi-Factor Authentication Server for OWA (unsupported) you need to complete the following steps:
- Configure MFA in Azure (see http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication for the steps on setting this up)
- Install the MFA server on-premises
- Configure and test users for MFA (see http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication as well for these steps)
- Integrate MFA into OWA.
Some of these steps are the same regardless of which service you are adding MFA to and some slightly different. I wrote a blog on MFA and VPN at http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication and this contains the general setup steps and so these are not repeated here. Just what you need to do differently
Step 2: Install MFA Server on-premises
This is covered in http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication, but the difference with OWA is that it needs to be installed on the Exchange CAS server where the authentication takes place.
Ensure you have .NET 3.5 installed via Server Manager > Features. This will install the .NET 2.0 feature that is required by MFA server. If the installation of the download fails, this is the most likely reason for the failure, so install .NET 3.5 and then try the MFA Server install again.
The install of the MFA server does not take very long. After a few minutes the install will complete and then you need to run the Multi-Factor Authentication Server admin tools. These are on the Start Screen in More Apps or the Start Menu. Note that it will start the software itself if given time:
Do not skip the wizard, but click Next. You will be asked to activate the server. Activating the server is linking it to your Azure MFA instance. The email address and password you need are obtained from the Azure multi-factor auth provider that was configured in Step 1. Click the Generate Activation Credentials on the Downloads page of the Azure MFA provider auth management page.
The credentials are valid for ten minutes, so your will differ from mine. Enter them into the MFA Server configuration wizard and click Next.
MFA Server will attempt to reach Azure over TCP 443.
Select the group of servers that the configuration should replicate around. For example, if you where installing this software on each Exchange CAS server, then you might enter “Exchange Servers” as the group name in the first install and then select it during the install on the remaining servers. This config will be shared amongst all servers with the same group name. If you already have a config set up with users in it and set up a new group here, then it will be different settings for the users. For example you might have a phone call to authenticate a VPN connection but use the app for OWA logins. This would require two configs and different groups of servers. If you want the same settings for all users in the entire company, then one group (the default group) should be configured.
Next choose if you want to replicate your settings. If you have more than one MFA Server instance in the same group select yes.
Then choose what you want to authenticate. Here I have chosen OWA:
Then I need to choose the type of authentication I have in place. In my OWA installation I am using the default of Forms Based Authentication, but if you select Forms-based authentication here, the example URL for forms based authentication shown on the next page is from Exchange Server 2003 (not 2007 or later). Therefore I select HTTP authentication
Next I need to provide the URL to OWA. I can get this by browsing the OWA site over https. The MFA install will also use HTTPS, so you will need a certificate and have this trusted by a third party if you want to support user managed devices. Users managing their own MFA settings (such as telephone numbers and form of authentication) reduces the support requirement. That needs the User Portal, the SDK and the Mobile App webservice installed as well. These are outside the scope of this blog. For here I am going to use https://servername/owa.
Finish the installation at this time and wait for the admin application to appear.
Step 3: Configure Users for MFA
Here we need to import the users who will be authenticated with MFA. Select the Users area and click Import from Active Directory. Browse the settings to imports group members, or OUs or a search to add your user account. Once you have it working for yourself, add others. Users not listed here will not see any change in their authentication method.
Ensure that your test user has a mobile number imported from the Active Directory. If not add one, choosing the correct country code as well. The default authentication for the user is that they will get a phone call to this number and need to press # before they can be logged in. Ensure that the user is set to Enabled as well in the users area of the management program.
Step 4: Configure OWA for MFA (additional steps)
On the IIS Authentication node you can adjust the default configuration for HTTP. Here you need to set Require Multi-Factor Authentication user match. This ensures that each auth attempt is matched to a user in the users list. If the user exists and is enabled, then do MFA for them. If disabled, then the setting for Succeed Authentication on the advanced tab comes into play. If the user is not listed, authentication passes through without MFA.
Change to the Native Module tab and select OWA under Default Web Site only. Do not set authentication on the Backend Web Site. Also enable the native module on ECP on the Default Web Site as well:
Then I can attempt a login to OWA or ECP. Once I successfully authenticate my phone rings and I am prompted to press #. Once I press # I am allowed into Exchange!
21 responses to “Exchange OWA and Multi-Factor Authentication”
Thanks for this detailed manual on setting up MFA for Exchange OWA.
We have an existing MFA server that authenticates users for Citrix. I am tasked with installing this for OWA on Exchange 2010. When I run through step 2, and I do not want to have 2 sets of configurations I choose the existing group and never get the screen where I am to check the box for OWA? How do I proceed?
Not entirely sure what you can or cannot see from your description. You need to install the MFA server on the Exchange Server for this to work, otherwise the virtual directory (/OWA) that you want to protect will not appear.
This works perfectly if you are using the option to call your mobile, but if you want to do SMS or SMS with a PIN it doesn’t work. The OWA Form immediately comes back with a ‘username or password isn’t correct’. Clearly we need it to prompt to provide the PIN but I can’t find out anywhere where this can be done. Any ideas?
So I’ve not tried PIN, but anything that does not include a UI to the user on what is happening behind the scenes is fraught with issues. We need to wait for ADAL support for Exchange Server on-premises (if it comes) which will rely on Windows Server 2016 ADFS (when that comes out).
This works perfectly if you are using the option to call your mobile, But Text not working.
Text requires a response from the user. Maybe the time taken to send back the response is timing out the OWA login form. Try replying quicker and see what happens! If that works then you know texts work, but as the user can only respond as fast as they are able to, you need to delay the login timeout. That is a setting in MFA Server.
I’ve tried to set up MFA for Owa but when I selected Native Module all components are checked and appears as inherited and I cannot uncheck and just set up for OWA Virtual Directory. Dou you know what is wrong?
Also i have faced same sitoution like “Jared” …
We are uesing exchange 2010 maybe message authentication dosent work with exchnage 2010 ?
As I mentioned above, any form of MFA auth that requires receiving a PIN requires you to enter it via the mobile device. For example, receive call and enter PIN then # to authenticate, or reply to a text and reply with the PIN. WHat you cannot do is enter the PIN into OWA as OWA does not support any form of data entry apart from username and password prompts. When (if) bearer auth comes to OWA then you will get this functionality. Bearer auth is also known as “modern auth” in Office 365. This presents a UI for data entry such as PIN entry if required.
Can we use the IIS plugin for OWA (exchange 2013) and use SMS for MFA ?
I think not because OWA does not have a token insert field or is this embedded in FBA when installing the plugin?
Correct. There is no way to return the code to the MFA app unless you control the forms that appear, and OWA does not have these forms. You can do one-way MFA auth though (phone call, app based auth etc.) where the response to activate the service is on the device and not by entering data to the application. Two way auth (i.e. reply to a text with a number) will not work in this scenario
In my enviroment MFA does not trigger if the server setup as “master” is not available, is that expected? I understand it is needed for config changes, but not being able to login with the master offline was surprising to me.
Yes, I discovered that too a few years ago and was disappointed with this, but changing the master fixed it. So master outages need to be limited to known outage events rather than treating it how you might an Exchange Server that is a member of a DAG
If I have already MFA on standalone servers for VPN authentication, can I install MFA on Exchange and join the same MFA group? Users are already setup for MFA for VPN I don’t want to have them go thru another MFA registration if I can just use existing.
To be in the same group, you need to be using the same MFA server. So either migrate the VPN system to a new set of servers and point IIS at the same, or two groups.
I already have MFA VPN authentication, can I add an account with a different name?
Can you please clarify your question further, as I am not sure what you are asking.
Does this work with exchange 2016 on a 2016 server?
the exchange server’s IIS isn’t showing up on the Native Module tab
the MFA is install on 2012 r2 could that be the problem?
The on-prem is working great and we using it for RDP sessions (via radius.. which is silly.. but oh well MS did it this way)
MS bought the product, they did not create it. The MFA server was a product called PhoneFactor back about ten years and has seen very little change in the UI since then (so still uses RADIUS). Azure MFA is the same product again, but is considerably different and is where all the dev work happens.
As for Exchange support, remember the note in the article about it not being supported. The correct way to get MFA support in Exchange Server is either publish it via Azure AppProxy, use ADFS for authentication (2013 and later) or the new and in preview (announced Ignite 2017) feature of using Azure AD to authenticate Exchange Server. You can plug MFA into all these with a whole range of options (like MFA if remote from LAN, or if on untrusted machine, or if high risk login etc.)
oh, i’m just bad and missed the whole part about installing it on the CAS server 🙂