Exchange Online Identity Models & Authentication Demystified (Part 4)

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


In part 3 of this article series revolving around the available identity models and the authentication story for Exchange Online, I provided you with an insight into the third identity model, which is federated identities.

Let’s get going. As usual, we have a lot to cover.

Authentication Story for Exchange Online Clients Up Until Today

As explained in the previous part of this article series, the authentication story for Office 365 clients had room for improvement. More specifically, it makes sense to introduce a more standardized authentication model, where all Office 365 clients use the same authentication method and endpoint. Doing so would also have a direct impact on the authentication experience seen from the end user’s perspective.

In the following we will go through what can be considered the two most frustrating Exchange Online client authentication pain points that exist for Enterprise customers up until today.

Credentials Must Be Stored on the Outlook Desktop Client Machine

Back since September 2007, where the Microsoft Business Productivity Online Standard Suite (aka BPOS) was announced, the Exchange Online workload has only had support for basic authentication when it comes to clients like the Outlook Desktop client, IMAP/POP clients, Exchange ActiveSync (EAS) clients, Exchange Web Services (EWS), and TLS secured SMTP clients.

Sure, we have without doubt come a long way since the “Microsoft Online Services Sign In” client that were installed on the end user’s client machine in order to configure Outlook (and other Office application) profiles and to authenticate the end user’s BPOS account in order to simulate an SSO experience but Enterprise customers still suffers, when it comes to basic authentication based clients.

Figure 1: MSOL Sign-In assistant

If you want to go on a serious trip down the memory lane of BPOS, you might want to read my BPOS article series from 2007. Just read through it myself recently, and it is quite incredible what has happened with the Microsoft cloud services since then.

With the launch of the first version of Office 365 (also referred to as wave 14 which were based on 2010 versions of the respective workloads) back in October 2011, the situation for Office clients was improved further with the introduction of the Microsoft Online Services Sign-in Assistant (or in short MOS SIA). The MOS SIA was a stand-alone package, which basically consisted of dynamic link library files (DLLs) and a Windows service (see more details here), that improved the login experience for Office 2010 clients. The MOS SIA was installed automatically on the client machine, if the Office 365 Desktop Setup tool was used. However, since Office 365 Desktop Setup tool required local administrator permissions on the client machine, most organizations deployed the MOS SIA package using their software deployment solution like SCCM.

Figure 2: Microsoft Online Services Sign-in Assistant Stand-alone package installed

On February 27, 2013, the second wave of Office 365 (also referred to as wave 15 which was based on 2013 versions of the respective workloads and the one that is in use as of this writing) was launched. Around the same time, Office 2013 was made generally available. With Office 2013, a MOS SIA is baked into the product removing the need to install the stand-alone MOS SIA package. However, the sign-in experience for Exchange Online clients were not improved as Exchange Online (now running Exchange 2013) still only supported basic authentication for the aforementioned non-browser based clients.

You see, despite the improvements made over time since the inception of Microsoft cloud services, because of the basic authentication requirement, the credentials have to be presented to Exchange Online, as in, they must be entered every time the Outlook Desktop client is launched or be saved in the Windows credential manager on the client. Refer back to the previous article in this series for the details around the proxy authentication flow that is the reason behind this requirement.

Figure 3: End user challenged for credentials in Outlook Desktop client

Since the credentials are stored client-side, it means that when the password expires or is changed for other reasons, the end user will need to enter it again and in order to avoid constant prompting ensure the updated password is saved to the credential manager.

Figure 4: Credential Manager on Windows 10 Client

Lack of Real Multi-Factor Authentication for Basic Authentication Clients

Multi-Factor Authentication (MFA) was made available to end users back on February 10, 2014. Although the MFA feature is based on Microsoft Azure, the feature is included in the covered Office 365 plans at no additional cost.There is also another more feature rich MFA solution available, but that one requires an Azure AD Premium subscription or the Enterprise Mobility Suite (EMS). You can find a comparison of the MFA editions here.

Although MFA wasn’t made available to end users before in February, 2014, it has been available to Office 365 administrative users since June 2013.

The MFA feature included with Office 365 includes support for mobile app, phone call and SMS as a second factor based authentication and has worked very well for browser based access to the Office 365 workloads, which in our case is Outlook on the Web (OotW) access to a mailbox.

Figure 5: MFA Enabled for End User accessing his mailbox using Outlook on the App (OotW)

However, the situation was far from ideal for rich clients, which in our case is the basic authentication based Exchange Online clients mentioned earlier since they, until recently, were not supported by any of the MFA options. Instead we needed to use so called App passwords for this client type.

An App password is a new randomly generated password that is created when MFA is enabled for an end user. It has nothing do to with MFA, but is merely just a new password that had to be used for basic authentication based clients. So in addition to the end users existing password, she now had to use the App password for Outlook on her desktop client, any mobile devices using the ActiveSync protocol and the other clients mentioned earlier.

Figure 6:
With MFA enabled, Basic Authentication based Clients use App Passwords

The App password can only be seen at the initial creation, so if the end user needs to set up a new basic authentication device or client later on, he needs to generate one more App password for this purpose now having three passwords in use. Yes, you see where this is going right? A lot of extra calls to the service desk and a confused end user wasting time messing around with App passwords.

As you can see in Figure 7, an App password is not something the end user will be able to remember as it is a complete random set of letters and not something he can relate to, like often is the case with passwords generated by the end user themself. This is of course good for security, but not for the end user. I fear some end users could come up with the “bright” idea of storing this password in an unencrypted fashion somewhere on their device or client, so they do not need to create a new one when/if required.

Figure 7: An example of an App Password

Although App passwords were only meant to be a temporary thing until modern authentication saw the day of light, it was a painful temporary period.

Good thing is, the Office 365 modern authentication team (formerly known as the Office 2013 modern authentication), that were established back in the beginning of 2014 were busy working on a new authentication story for Office 365 clients.

This concludes part 4 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 read the other parts in this article series please go to:

About The Author

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