12 Jan Switching to Modern Authentication mode in MailStore
Microsoft have announced that Basic Authentication is being deprecated and that they will start turning this authentication type off on 365 tenants beginning October 2022.
MailStore version 13 onwards makes it possible for Microsoft 365 customers to tighten up their security by utilising Microsoft’s Modern Authentication integration.
This article aims to explain what changes have been made in MailStore to support Modern Authentication and what the process is to convert a MailStore installation over from using Basic Authentication to Modern Authentication.
So what changes need to be made in MailStore?
All the steps for configuring MailStore to archive an Office 365 Platform using Modern Authentication all covered in this MailStore ‘Implementation guide’
However if you are converting an existing MailStore installation over from Basic Authentication to Modern Authentication, these are the main steps we would advise: (please check each step carefully)
- Stop or delete all existing jobs from running by converting them to ‘Manual’ mode. An existing “journaling” job doesn’t need to be removed.
- Remove all existing basic authenticated users from MailStore with the exception of the default admin account (If you have any existing custom permissions for users to access other archives, you may want to make a note of these before you remove them and recreate them once the new users have been re-synced).
- Synchronise your users again using the new Directory Services method ‘Microsoft 365 (Modern Authentication)’ – the details are in this guide. or you can follow this video
- Once your users are synchronising correctly try logging in as one of the users using the MailStore Web Interface – this will check the verification is working correctly.
- Create new archive jobs using the Email-Servers > Microsoft 365 Type to mirror any existing jobs you have set up using Basic Authentication. See this video for an overview
- If the username format differs from the old username format, you may find you now have duplicate archives. To resolve this, rename the old archive so it has the username of the new archive. This action will cause MailStore to merge both the old archive and the new archive into a single new username archive.
The remainder of this guide explains how Basic Authentication differs to Modern authentication, to help you understand the mechanisms involved.
Basic Authentication
This is the model that most users and admins will be familiar with. It verifies access via a username and password for the session. In MailStore, this verification can be used to sync users via the Directory Services type ‘Microsoft 365 (Basic Authentication)’ or through the use of any ‘Microsoft Exchange’ archive jobs for single or multiple mailboxes:
In order to give MailStore access, the administrator must enter the username and password of a valid Microsoft 365 account, or a service principle that has the valid rights.
But here lies the weakness…
All that is needed for anyone to connect and gain access is those two details, the username (often a known email address) and the associated password.
In the case of the Multiple Mailbox Job in MailStore, if a hacker knows the username and password of an admin account, in effect they can access the entire contents of all users mailboxes, so keeping those details both strong and on a ‘need to know basis’ are extremely important.
Microsoft knows this and have provided the option to implement Multi Factor Authentication (MFA) for user access to better increase security. This is an evolving solution and also includes new methods and restrictions for users in different ways depending on whether they are connecting from known ‘Trusted devices or networks’ or not.
You may already be familiar with MFA for user access and this does indeed help users secure their connection. However, when 3rd party applications simulate a client type connection by logging in using the user details, requiring MFA is not really option as the MFA method isn’t something the application can gain access to.
Lets take the example of being sent a one time code via SMS text, or using an authentication app to generate the code. The historic way around this was the use of assigned ‘App Passwords’ for each user account which only applications like MailStore should know. However, in effect, we have just circumvented the whole point of using MFA by saying its ok you can still get in with a unique username and password just don’t give it out to users – better but not by much!
Microsoft is well aware of this problem and actively recommend against the use of App Passwords and instead would rather remove the Basic Authentication method for users and applications all together, and recommend an entirely new method of authenticating users we refer to as ‘Modern Authentication’.
So what is Modern Authentication?
Well, it’s new, that’s a given in the name, but fundamentally the main thing we are talking about here in terms of Microsoft authentication is that we no longer allow anything other than users to log into Microsoft using the account credentials, and we can therefore force users to use additional MFA methods to further secure their own access from only known trusted devices and we disable all old ‘App Passwords’ that may have existed.
So where does this leave the 3rd party applications like MailStore if they can no longer use an App Password?
Well, they are given a completely new method to validate whether the user is valid or not utilising an authorisation mechanism called OAuth 2.0.
This mechanism is based around a trust relationship between the user, application (MailStore) and the identity provider (Microsoft). When a user wishes to log into MailStore, MailStore in effect redirects that user to login to Microsoft but includes a known ID token for them to use as a reference if Microsoft verifies them (after any MFA requirements) they are given a specific URI (URL and Verification Token) to return to the Application (MailStore), as a final acknowledgement of them being successful.
So how does this change how users log into MailStore?
First, let’s think about how users log into MailStore with simple Basic Authentication.
The user is asked within the MailStore Client or Web client or Outlook Add-in for both a valid username and password which are given to MailStore over a secured connection.
MailStore takes these details and acts on behalf of the client to simulate a login to Microsoft using those details. If they are valid it can allow the user access.
Simple but ultimately not very secure.
Let’s now have a look at what’s actually happening when the same user logs into MailStore if they are using Modern Authentication.
Step 1: Send Username
When the user accesses any MailStore features in the Outlook Add-in they are asked to enter their MailStore user identification (email address). You may have noticed this is different from previous versions of MailStore that asked for both the username and password on the same screen.
Step 2: Return Sign-in URI of identity Provider
MailStore checks the user against the MailStore user list to see if it is either a Directory Synchronised user that is using Modern Authentication or a local MailStore integrated user that has a stored local password. In the case that the user is synchronised with Microsoft, it then sends back a Sign-in URI of the Identity Provider they should use for the client.
Step 3: Authenticate
The client then connects to the Identity Provider using the URI that was provided (Microsoft in our example), which prompts them to authenticate with that provider as usual. It’s at this stage that they would have to enter any MFA they had set up.
Note: if the user is already logged into a Microsoft account either directly within Windows or because they already have a valid web session open then they will not need to log in again. This is the ‘single sign-on’ method.
Step 4: Return Redirect URI + ID Token
Once authenticated, the Identity Provider matches the user against the application registered in the Azure AD API and provides an ID Token using the application certificate configured. Only the registered application can use this token. This token along with the Redirect URI for the application are sent back to the client.
In the case of MailStore the Redirect URI needs to be a valid MailStore server hostname in respect of the client. Typically the FQDN of the server is used.
For example: http://mailstoreserver.mydomain.com:8462/oidc/signin
Step 5: Send ID Token to Redirect URI
The client then opens a direct HTTPS connection to the URI address provided ID token back to the MailStore Server.
Step 6: Validate ID Token
MailStore takes the ID Token provided by the client and requests the user information for that token. This user information is provided and is the final verification that the user is allowed access.
Step 7: Mark session as Authenticated
MailStore grants the user access and marks the session as authenticated.
The important difference with this method is that at no point does MailStore know the user’s password or MFA details