Exchange Online Identity Models & Authentication Demystified (Part 7)

If you would like to be notified of when Henrik Walther releases the next part in this article series please sign up to our Real Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:


In part 6 of this article series revolving around the available identity models and the authentication story for Exchange Online, we enabled modern authentication for our Exchange Online tenant and connected to a mailbox using an Outlook desktop client that had ADAL enabled.

In this part 7, we will continue where we left off in part 6.

Let’s get going.

The Definition of Multi-Factor Authentication

As we mentioned back in part 4 of this multi-part article, the multi factor authentication (MFA) story for basic authentication based authentication clients such as the Outlook desktop client was very poor as it relied on so called “app passwords”, which really did not have much to do with MFA whatsoever.

So what is the definition of multi-factor authentication? Well, it really lies in the words. It is a control access method enforced in order for an end user to access a solution, system, network or service. In addition to the end user’s credentials, that usually consists of a username and password and an extra factor or should we say piece of evidence such as something the end users know, have or are is required in order to gain access. In short, it’s an extra layer (factor) of security, which is extra important for services such as Office 365 that are directly exposed to the Internet.

When it comes to Office 365, the “app passwords” feature that basic authentication clients could utilize was just a new password that the end user needed to use to authenticate using a basic authentication client. IT was not an extra password that had to be used, but a password that simply replaced the old password for these clients.

Back in the days when it was companies such as RSA that ruled this market, the end user was often provided with a USB dongle (hardware token), which in RSA lingo was referred to as SecurID. Naturally, this has shifted towards software tokens, mobile device apps and for larger organizations smartcards (physical or virtual).

Fortunately, modern authentication improves the MFA story significantly. As a matter of fact, we now have a true MFA story for all Exchange Online clients.

Office 365 Multi-Factor Authentication Versions

When it comes to MFA, we have three versions to choose between:

  • Multi-Factor Authentication for Office 365 This is the version that can be used with the Office 365 workloads without any additional charges. It comes with an Office 365 subscription by default.
  • Multi-Factor Authentication for Azure Administrators This is the same subset of MFA capabilities as the previous one but for Azure Administrators specifically. This one is also free of charge and can be utilized by Azure administrators in general but also Office 365 Global Administrators, which of course is strongly recommended as these accounts have pretty powerful permissions.
  • Azure Multi-Factor Authentication Lastly, we have the Azure Multi-Factor Authentication which offers a richer set of features and configuration options plus includes advanced reporting and support for a range of on-premises and cloud based applications. It is important to note this requires Azure Active Directory Premium (ADDP).

A comparison chart that lists the three MFA versions and included features for each can be found here.

In this article our focus will be on the free MFA version included with an Office 365 subscription. I will cover the MFA version included with AADP in another article series.

Enabling Multi-Factor Authentication for an End User

Okay so as you know, we enabled modern authentication on the tenant level in our previous article and connected to an Exchange Online mailbox using an Outlook 2016 desktop client, which means that we did not have to set any registry keys on the client machine.

In the following, we will enable MFA for the respective mailbox user, which just requires a couple of clicks.

Launch the Office 365 Portal and click “Active Users” and then “Set up” to the right of “Set Multi-factor authentication requirements” as shown in Figure 1 below.

Figure 1: Click Set up under Active Users in the Office 365 Portal

This will take us to multi-factor authentication user management section in the Azure Active Directory portal.

Figure 2: Multi-factor authentication user management section in the Azure Active Directory portal

In order to enable MFA for a user tick him or her and then click “Enable” under “quick steps”. The dialogue box in Figure 3 will appear. Click “enable multi-factor auth”.

Figure 3: Enable multi-factor authentication

We will now be told the update was completed successfully and can click “close”.

Figure 4: Updates completed successfully page

We have now enable MFA for a user. However, before we move on to test MFA from the client, let’s click on the “service settings” tab on the “multi-factor authentication” page.

Here we can specify whether a user is allowed to create an app password for non-browser app purposes. We also have an option to suspend multi-factor authentication for remembered devices, which is a pretty neat feature used to specify after how many days a remembered device should be forced to re-authenticate.

Figure 5: Multi-factor authentication service settings

End User MFA Configuration Options

After MFA has been enabled for the user, the first time he logs on again he will be presented with the page shown in Figure 6. Because MFA has been enabled, he needs to set up his account. More specifically, specify which second factor he wishes to use to complete authentication.

Figure 6: End user prompted to complete MFA set up

Clicking “Set it up now” will take the user to the page shown in Figure 7. Here he can specify the second factor authentication method.

The default is “Authentication phone”, which will call or send a text message to the mobile number specified. If the calling method is selected, the user then needs to press hashtag (#) and he will be authenticated and taken to the respective workload. If text message is selected, he will need to enter the code received on the login page.

Figure 7: Authentication phone

The second method is “Office phone”, which can be used to specify a good old Office phone for those of you who still have one. You can even specify the extension. Note you should not use a Lync phone.

Figure 8: Office phone method

The last method is “Mobile app”, which makes it possible to use the Azure authentication app. We can receive a notification or use a verification code.

What I personally like about this method is you can use finger touch authentication in the app.

Figure 9: Mobile app method

After having chosen the second factor authentication method, the user will be taken to the page shown in Figure 11. As you can see, he will be provided with an app password he can use for clients that do not support ADAL.

Figure 10: Generated app password for clients not supporting ADAL

Testing MFA from a Client Machine

Ok let’s switch to a device with the Outlook desktop client installed. First, I will show you what an end user should expect when setting up a new Outlook profile. If not connected to the domain, the user will get the login page shown in Figure 11 which is the login page on a Web Application Proxy (WAP) server.

Figure 11: WAP server login page

After the user has specified UPN and password, he will be redirected to the “” login page for Office 365/AAD as shown in Figure 12. In this example the default MFS authentication method has been selected so the user will need to answer the call and press hashtag (#).

Figure 12: User is called on his mobile phone for the second factor authentication

If the user was domain joined and domain connected, he would not be taken to the WAP Login page, but directly to the login page shown in Figure 13.

If the end user already had an Outlook profile created and MFA is enabled, he will be prompted in a similar fashion depending on whether he is on an external network or domain joined and domain connected. If on an external network, he will need to enter his credentials on a WAP server as shown in Figure 13.

Figure 13: Prompted for credentials on a WAP server

Now the use will be called on his mobile device.

Figure 14: End user called on his mobile phone

And just like that, the user is connected to his mailbox in Exchange Online.

Now remember from here the logon and refresh token behavior I discussed earlier will kick in, which means that subsequent launches of the Outlook desktop client won’t prompt for any credentials if the client is used in a frequent manner.

Figure 15: Connected to his Mailbox in Exchange Online

This concludes part 7 of this multi-part article in which I provide you with an insight into the new Modern Authentication story and how it affects clients connecting to Exchange Online.

If you would like to be notified of when Henrik Walther releases the next part in this article series please sign up to our Real Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

About The Author

2 thoughts on “Exchange Online Identity Models & Authentication Demystified (Part 7)”

  1. Excellent article. Thanks for this. It collects a lot of topics and presents them in an excellent fashion. Modern auth is great when planned for properly, and many admins are required to know a lot of things to get this working.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top